Investigate cross-boundary reliability coverage after recent merges #306

Context

A post-merge review of PRs #292 through #301 found two confirmed regressions. Those are being fixed separately in a targeted PR. This issue records the remaining recommendations so they can be investigated with evidence rather than folded into that small bug-fix patch.

These are not confirmed product defects. They are cross-boundary reliability and test-hardening opportunities.

Follow-up investigations

1. Exercise composer intent through the full turn pipeline

• Add a focused integration harness that starts at composer state, selects an explicit-only Scient skill, fans out to multiple models, and verifies both child requests and both server skill scopes.
• Inventory composer-originated turn producers (normal, background, fan-out, queue, edit, steering, and follow-up).
• Evaluate a narrow typed internal boundary that requires each producer to handle semantic fields such as the selected-skill snapshot.
• Keep the public wire field optional for compatibility and preserve intentional differences between turn kinds. Do not introduce a universal builder unless the inventory proves it simplifies the system.

2. Test durable queue state against worktree cleanup

Create an integration scenario covering queued work in paused, editing, blocked, and awaiting-completion states:

1. Leave queued intent pending in a clean worktree.
2. Make that worktree eligible for cleanup.
3. Run cleanup.
4. Resume the queued work.

Define and assert the intended policy: either preserve the checkout while queued intent remains, or safely recreate it without losing intent or accepting stale workspace authority.

3. Test project reassignment during long-running document builds

• Start an HTML/PDF or LaTeX build.
• Reassign the project or replace its workspace root before publication.
• Verify publication revalidates the current binding and immutable revision.
• Verify neither publication nor temporary-file cleanup can write into or remove content from the replacement workspace.

The existing publication checks look directionally correct; this should prove the composed behavior rather than assume a vulnerability.

4. Preserve CI evidence and investigate the compute flake only if it recurs

• Keep per-shard JSON reports and per-attempt artifacts when CI jobs are retried.
• If the scheduler-sensitive compute failure recurs, preserve the failing artifact and diagnose the timing boundary from evidence.
• Do not mask an unproven failure with broader retries, longer timeouts, or weakened assertions.

Acceptance criteria

• Each investigation starts with a reproducible scenario and records whether a real defect exists.
• Any resulting product change is delivered in its own focused PR with behavior-level tests.
• No queue, workspace-authority, publication, provider, or cleanup policy changes without a documented product/architecture decision.
• No rollback of the recent upstream integrations without evidence of a concrete regression.

Out of scope

• The two confirmed regressions from the review (multi-model selected-skill propagation and pending citation dictation submission) are handled in the targeted fix PR.
• No Pi catalog or platform rollback is recommended by the current evidence.