feat(canvas): add creation slash command

[beruro]

Problem

Canvas creation has no first-class composer command. Users must describe the desired UI indirectly, and the inline slash menu and pinned-action surface do not share a Canvas entry. A generic skill pill also gives the Agent no deterministic signal that this is a new Canvas creation request, so bare commands and lookalike text can be handled inconsistently.

Solution

Register /canvas in one shared built-in command list used by the in-session composer, Session Creator, and pinned-action picker. Both selection paths insert the same atomic command pill, with a Canvas-specific icon in the editor and sent-message history.

At the submit boundary, preserve the serialized pill as the visible/persisted user message while projecting only exact /canvas [request] commands into an Agent-only creation contract. An instructed command requires one render_inline_canvas call for a new Canvas; a bare command asks for requirements without calling the tool. Ordinary prose and lookalike commands remain unchanged. The command description is localized in all existing session locales.

Potential risks

• Creation still depends on the selected Agent exposing render_inline_canvas; this PR does not add or change backend tool availability.
• The Agent-side projection intentionally runs only where enableAgentInterceptors is enabled. Opt-out behavior is covered so specialized composers retain their existing dispatch contract.
• A packaged Tauri end-to-end run was not performed in the isolated worktree. Rendered component tests cover pill insertion and both icon surfaces, but native session/tool dispatch remains an unverified manual path.
• There are no persistence, schema, public IPC, or wire-format changes. Rollback is the single commit in this PR; existing messages and Canvas data require no migration or cleanup.

Architecture audit

Covered all 10 audit layers:

1. Compilation: final TypeScript check passed.
2. Liveness: every new production helper is wired into a composer or submit path.
3. Types: the command is represented by SLASH_ACTIONS.CANVAS; helper-only option types remain private.
4. Naming: Canvas creation is kept distinct from Canvas preview and revision concepts.
5. Control flow: parsing is start- and end-anchored; ordinary prose and lookalikes are rejected.
6. Boundaries: shared command registration/insertion is generic; the Canvas Agent contract stays at the submit boundary.
7. Domain vocabulary: displayText, agentBase, and agentContent make the two projections explicit.
8. Serialization: the persisted user message is unchanged; no backend wire schema changes.
9. Initialization parity: ChatPanel and Session Creator consume the same registry and insertion helper.
10. Resolution: no new multi-field fallback resolver or canonical-ID logic was introduced.

Effects: none added or materially modified. No timers, polling, subscriptions, workers, caches, or retained background resources were added.

UI audit

Report: docs/frontend-ui-audit-2026-08-10/CanvasSlashCommand.md

• Fix: 0
• Keep with reason: 6
• Abstract: 0
• Sweep candidates: none

No screenshot is attached because the isolated worktree was not launched as a signed desktop build. The changed states are covered with rendered jsdom tests for pinned insertion, editable pill rendering, and sent-message rendering.

Verification

Passed:

• eslint on the 18 changed TypeScript/TSX production and test files.
• vitest run on the seven Canvas command, projection, insertion, pinned-action, composer-pill, and sent-message test files: 7 files, 17 tests passed.
• for f in src/i18n/locales/*/sessions.json; do python3 -m json.tool "$f" >/dev/null || exit 1; done
• tsc --noEmit --pretty false
• git diff --check
• Staged-diff scan for secrets, personal paths, debug statements, build output, and unrelated files: no findings.

Not run:

• Full Vitest suite; the focused behavioral set covers the changed lifecycle, and the final full-repository check was limited to TypeScript as agreed to avoid repeated whole-repository scans.
• Packaged Tauri manual test; native tool dispatch is the remaining verification risk described above.