feat(commands): add typed execution scope

[joelteply]

Summary

• add typed CommandScope / CommandParams.scope as the command routing and audit boundary
• add CommandBase.naturalScope so commands can declare their native room/grid/project scope centrally
• inject natural scope through CommandDaemon before grid routing, while leaving generic commands unmodified unless they declare a natural scope
• mark AIRC send as room-scoped and grid send as grid-scoped
• separate domain fields that previously overloaded scope into skillScope and proposalScope

Work card: e7b4f8ec-64c5-4b9a-b294-91541784ed25 / [L1-3] CommandBase.naturalScope + CommandParams.scope.

Verification

• npm run build:ts
• precommit gate: TypeScript compile, ESLint baseline, chat roundtrip passed; browser ping timed out and was skipped by the existing hook policy
• pre-push gate: TypeScript compile, ESLint baseline; Rust skipped because no Rust-relevant changes

[joelteply]

Reviewed against #1439 §2.1 + my §2 (MULTI-PEER-COMMANDS) table. The typed CommandScope shape is sound — system/user/session aligns with existing EventScopeDefinition vocabulary, room/project/persona/resource add the entity-level partitioning continuum needs. Renaming overloaded skill/proposal scope to skillScope/proposalScope is a good collision cleanup. LGTM as a slice.

One substantive observation worth surfacing before more commands adopt this:

Two 'scope' concepts that should probably be two fields. #1439 §2.1 defines naturalScope as a ROUTING decision ('local' | 'environment' | 'grid' — where the command runs). This PR's CommandScope.type is an AUDIT/PARTITION decision ('system' | 'user' | 'session' | 'room' | 'project' | 'persona' | 'grid' | 'resource' — what entity owns the command's effects). The values grid and resource blur the line — grid here means 'this command's audit lives at grid scope', not 'route this command to another peer'. Two different axes, both called 'scope'.

My §2 command classification table uses the routing axis (local | environment | grid) matching #1439 §2.1. After this PR lands, my §2 table would need an additional column for the audit/partition scope to be complete. Or — cleaner — rename one of them so the distinction is in the type name:

• naturalScope: 'local' | 'environment' | 'grid' (routing, per docs(grid): GRID-BUS-ARCHITECTURE — airc as universal bus + grid substrate #1439)
• auditScope: CommandScope (audit/partition, per this PR)

That keeps both concerns first-class without callers having to guess which 'scope' they're setting. Not blocking — the renaming can be a follow-up before downstream commands depend on the current shape.

Other observation: the alignment with EventScopeDefinition (system/user/session) is a deliberate choice or a coincidence worth pinning. If deliberate (events + commands share scope vocabulary), a one-line comment in CommandScope's doc would help future readers see the connection. If coincidental, deduplicating into a shared base type would shrink the eventual maintenance surface.

LGTM for L1-3. Will update my §2 table to reflect the audit-scope shape once this lands + the naming question is resolved.