v0.8.4: Documentation refresh + surface sizing fix

Docs pass covering v0.7.5–v0.8.3 module additions:
- STARLARK-REFERENCE: workspace module, permissions module, settings.has_capability()
- EXTENSION-GUIDE: capabilities manifest, vector(N) column, user_permissions,
  gate_permission, updated permissions list
- Tutorial reviewed for v0.7+ accuracy (no changes needed)

Surface sizing fix: .surface-inner converted to flex column layout so
the shell topbar and surface container share vertical space correctly.
All surface containers changed from height:100% to flex:1;min-height:0.
Eliminates 44px scroll cutoff on docs, admin, settings, and all
extension surfaces.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/EXTENSION-GUIDE.md

@@ -72,7 +72,7 @@ Every package has a `manifest.json` at its root. Example for a surface:
 | `icon` | no | Emoji icon for sidebar/menu |
 | `route` | surfaces | URL path (e.g., `/s/my-surface`) |
 | `auth` | no | `authenticated` (default) or `public` |
-| `permissions` | no | Capabilities requested: `db.write`, `http`, `notifications`, `secrets`, `realtime.publish` |
+| `permissions` | no | Sandbox capabilities: `db.write`, `db.read`, `api.http`, `notifications`, `secrets`, `realtime.publish`, `connections.read`, `workflow.access`, `batch.exec`, `files.read`, `files.write`, `workspace.manage` |
 | `api_routes` | no | Array of `{method, path}` for extension HTTP endpoints |
 | `api_schema` | no | OpenAPI documentation for extension API routes (see below) |
 | `db_tables` | no | Table definitions (see below) |
@@ -80,11 +80,23 @@ Every package has a `manifest.json` at its root. Example for a surface:
 | `exports` | libraries | Functions exported for other packages |
 | `hooks` | no | Event bus subscriptions |
 | `config_section` | no | Settings/Admin panel injection (see below) |
+| `capabilities` | no | Environment requirements (see below) |
+| `user_permissions` | no | Permissions this extension registers for users (see below) |
+| `gate_permission` | no | Permission checked before `on_request` executes |
 | `schema_version` | no | Integer for additive schema migrations |
 
 ## db_tables Schema
 
-Tables are automatically namespaced as `ext_{package_id}_{table_name}`. Column types: `text`, `int`. Every table gets an auto-generated `id` primary key and `created_at` timestamp.
+Tables are automatically namespaced as `ext_{package_id}_{table_name}`.
+Every table gets an auto-generated `id` primary key and `created_at` timestamp.
+
+Column types: `text`, `int`, `vector(N)`.
+
+The `vector(N)` type stores N-dimensional float vectors for similarity
+search via `db.query_similar()`. Storage adapts to the backend:
+Postgres + pgvector uses native `vector(N)` with HNSW indexes,
+Postgres without pgvector uses `JSONB`, SQLite uses `TEXT`. N can be
+1–4096. See the [Starlark Reference](STARLARK-REFERENCE) for query API.
 
 ```json
 "db_tables": {
@@ -137,6 +149,51 @@ Extensions can optionally declare an `api_schema` array in their manifest to pro
 
 Only `path` and `method` are required. All other fields are optional. Malformed entries are logged and skipped without blocking extension loading.
 
+## Capabilities
+
+Extensions can declare environment requirements via the `capabilities`
+manifest field. The kernel validates these at install time.
+
+```json
+{
+  "capabilities": {
+    "required": ["postgres"],
+    "optional": ["pgvector", "workspace"]
+  }
+}
+```
+
+- **required** — install is rejected (HTTP 422) if any capability is missing.
+- **optional** — install succeeds with a logged warning. Query at runtime
+  with `settings.has_capability("pgvector")` to adapt behavior.
+
+Detected capabilities: `pgvector`, `workspace`, `object_storage`, `s3`,
+`postgres`. The admin can view detected capabilities at
+**Admin > System > Capabilities** or via `GET /admin/capabilities`.
+
+## User Permissions
+
+Extensions can register custom permissions that the admin assigns to
+user groups. This controls access to extension features beyond the
+sandbox permission model.
+
+```json
+{
+  "user_permissions": ["image-gen.use", "image-gen.admin"],
+  "gate_permission": "image-gen.use"
+}
+```
+
+- **user_permissions** — on install, these are merged into the kernel's
+  permission registry. On uninstall, they are removed. The admin assigns
+  them to groups in **Admin > Groups**.
+- **gate_permission** — if set, the kernel checks this permission before
+  calling `on_request`. Unauthorized users get a 403 without the
+  extension code executing.
+
+In Starlark, check permissions inline via `req["permissions"]` or call
+`permissions.check(user_id, "image-gen.use")`.
+
 ## Starlark Sandbox API
 
 Starlark scripts run server-side with a 1M operation budget and no