feat(daemon): annotate selection with fork's session clip on fork Runs

[edwin-zvs]

Summary

When a selection Run (with or without the optional instruction) is dispatched to an interactive fork, the daemon now appends the fork's @{session:<id>} clip to the selected text at dispatch time — the same convention selection verbs (spec 0089) and instant dispatch (spec 0066) already follow. The Program document immediately shows where the work went, and the clip renders the fork's live state in place.

• The annotated block keeps its pending shimmer, re-declared with a plain "Running" tooltip (the clip changes the block's content id, so the shimmer decl targets the post-clip id via keep_pending).
• Best-effort: if the selection anchor no longer applies verbatim (concurrent edit / ambiguity), the Run proceeds without a clip instead of failing — the fork already exists and is booting.
• Shift+Run (owner-targeted) and non-fork callers are unchanged: no session clip — the work happens in the session the user is already looking at.
• The execute response returns the post-annotation program/blocks and a re-snapshot of the active run, so clients render the clip without waiting for the broadcast.

Spec 0076 updated with the annotation decision.

Verification

• cargo test --workspace — green (exit 0).
• New/extended e2e tests:
  • program_selection_fork_run_delivers_and_submits_prompt now also asserts the clip lands in the returned + persisted markdown and the block shimmers with the "Running" tooltip.
  • program_selection_owner_run_adds_no_session_clip asserts the Shift/owner path stays clip-free.

🤖 Generated with Claude Code