refactor(dispatch): make typed scope authoritative across policy and worker context

[akougkas]

Problem

Adding typed intent is insufficient if project-rule selection, worker prompt compilation, policy admission, and write enforcement continue deriving paths independently. A declared path must not disappear or change meaning between those boundaries.

Goal

Make structured dispatch intent authoritative for policy-bearing scope and worker context.

Dependencies

Blocked by #155.

Scope

• Select path-scoped project rules from declared relevant/read/write paths.
• Compile worker context from the same canonical path set.
• Use declared write scope for authority admission and write-boundary setup where applicable.
• Carry expected outputs and verification intent into result-contract/review context without turning them into unverifiable claims.
• Define deterministic precedence when fleet contracts, agent profiles, or request-level fields further narrow scope.

Acceptance criteria

• Every rule matching a declared work path reaches the worker; unrelated rules do not.
• The path set used by selectActiveRules, compileWorker, authority admission, and write-boundary enforcement has one canonical owner.
• Narrowing is monotonic: downstream stages may reduce authority but cannot widen declared roots.
• Expected outputs and verification requirements reach reviewer/result-contract context as requirements, not evidence.
• Contract tests cover nested rules, overrides, exact files, directory roots, mixed read/write intent, and profile/fleet narrowing.
• Existing fix(prompts): project rules and operator profile never reach a worker #96/feat(dispatch): record which project rules and operator profile reached a worker in its RunReceipt #104 behavior remains intact and gains typed-scope coverage.

Implementation seams

Relevant owners include src/domains/context/project-rules.ts, src/domains/prompts/compiler.ts, dispatch admission/plan compilation, worker-spec construction, and write-boundary enforcement.

[akougkas]

Merged on v0.3.8. Verified with npm run ci on the integrated branch: 4977/4977.

Two decisions recorded for #159 and #163, which build on this.

Grammar. The canonical owner is src/core/path-boundary.ts, and it adopts the fleet write boundary's existing grammar: repository-relative POSIX paths, a trailing slash meaning a subtree, its absence meaning an exact file, and globs, absolutes, backslashes, . and .. refused. That choice was forced by the constraint that a fleet contract valid today must keep meaning what it means today.

Replace, not union. When intent is present the declared set replaces prose inference. This can drop a project rule the inference would have activated, so the divergence is reported rather than silent, through a typed dispatch.scopeNotice bus event projected into the transcript.

Not done here, and deliberately. expectedOutputs still accepts arbitrary prose, because normalizePathEntry only rejects separators, absolutes and escapes. A live 0.3.7 receipt sealed four prose phrases as repository-relative paths. Tightening it needs its own issue.

Fleet writes stays post-run. Wiring it into spec.writeRoots would hit the policy engine's blanket refusal of bash, verify and dispatch under an active write root, which every fleet step running a command depends on. The refusal is honest: the target check can only prove containment given a concrete write path. Pre-emptive fleet confinement needs a command sandbox and is out of scope.