feat(docs): app-owned context-dependent skills + live-URL scope

[jordanssv]

What

Docs becomes the first app with a real, app-owned Actions catalogue and context-dependent skill scopes — riding the extraSkills seam from #48, and giving the agent a docs context skill that grounds on the live Google Doc.

1. Docs context skill (src/apps/docs/context.md + context.json) — materialized as a SKILL.md: the open surface is a live Google Doc (not a brains board), reads via the browser, all writes through gdrive-files act_on_integration (read_document / edit_doc_text / write_document), approval honesty ("never claim it changed until the approval executes; re-read to verify"), formatting/fact preservation, and the honest v19 limits (64 KB html cap, no surgical colour).

2. App-owned docs skills (src/apps/docs/skills.ts → HostSurface.skills) — the research-board set: Draft-from-a-note / Polish / Summarize / Notes→brief / Review comments / Redesign (open doc), plus "Summarize recent work" (docs home). The central catalogue's docs entries are removed — exactly what the app-contributed seam's comment invites — so the rail shows one set, app-owned. Gmail's stay central until it migrates.

3. Context-dependent scope from the live tab URL — the engine emits browser-navigated {key, url} on every main-frame address change (Host::emit_navigated ← CEF on_address_change); DocsTab derives docs-home (list) vs doc (/document/d/<id>/) and carries the file_id to skills via content metadata. Chromium-engine only; the mock falls back to content presence.

4. One addition to the seam: Skill.instruction — the composed-path counterpart to brief. App-contributed skills that need the workstation runner (content-port read + {CONTENT}/{TITLE}/{METADATA}/{BRIEF} splices) carry instruction; docs skills need {METADATA} for the open doc's file id. brief stays the raw fast path; one field + a one-line fallback in composeSkillPrompt.

Why URL, not DOM, for scope

The URL is the most stable contract Google exposes (/document/d/<id>/ is the Drive API key; on_address_change is browser-level, invisible to their frontend). Doc content comes from the Drive API, never scraped. A DOM observer (selection, active comment — ARIA-anchored, fail-soft, gmail-style) is the planned enrichment slice, not this one; same for a drift canary in the eval lane.

Notes

• Rebased on dev @ f6eb11c; context manifest regenerated under feat(context+agents): native per-app workspaces — sessions load skills the CLI's way #48's engine (6 contexts).
• This is also the file_id plumbing the scoped-act-grants work (BRNS-MCP-053 — desktop live edits) sits on.
• Draft: field-testing on stage continues; observer + canary follow-ups tracked under BRNS-DESK-009/-003.

Testing

• svelte-check 0 errors (737 files) · lint:imports / lint:manifests / lint:size green · 890 vitest pass (the 72 unhandled jsdom worker errors reproduce identically on dev's tip in a clean worktree — pre-existing, local Node v20 vs the dep bump).
• skills.test.ts updated: pins that central SKILLS no longer names docs scopes (they're app-contributed now).
• CEF preflight passes; manual: docs home shows "Summarize recent work", opening a doc switches the rail to the six doc skills, navigating back switches home — verified live against stage (gdrive-files v19).

🤖 Generated with Claude Code