Make v18-to-v19 migration discover graphs before confirmation

[flyingrobots]

Problem

The published v19 README used --graph events as a literal example. Running that command against a repository containing other graph namespaces reports migration: empty, which makes a missing graph look like a successful no-op.

A repository may contain multiple independent git-warp graphs under refs/warp/<graph>/...; the migration must never imply that events is global or special.

Result

• Fail with Graph not found when the selected graph namespace is absent.
• List discovered graph names, ref/writer counts, and whether each graph is current v19, requires migration, or has an unsupported marker.
• Replace literal events migration examples with an explicit graph-name placeholder and discovery-first instructions.
• Render operator output and progress with Bijou.
• Ask for confirmation before inventory, scratch migration, or apply work; provide an explicit --yes path for automation.
• Preserve multi-graph isolation and add regression coverage for selecting a missing graph in a multi-graph repository.

Safety

Discovery is read-only. --apply must continue to update only the explicitly selected graph after scratch verification and compare-and-swap checks.

[coderabbitai]

🔗 Related PRs

#664 - Resolve priority-next runtime boundary batch [merged]
#726 - Move graph exports behind v19 public API boundary [merged]
#732 - Fix: anchor state-cache payloads against Git GC [merged]
#764 - Adopt persistent Git object sessions and close them safely [merged]
#788 - Add one-shot v18-to-v19 retained-substrate migration [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[flyingrobots]

Operator-flow decision from the live v19 review: the retained substrate does not require a two-invocation dry-run/--apply sequence. The documented interactive workflow should be one invocation: discovery -> plan/capacity estimate -> explicit confirmation -> scratch rewrite -> apply -> verification. --dry-run should explicitly stop after the plan; --yes should authorize noninteractive automation. The existing --apply flag may remain as a compatibility alias, but should not require a human to rerun the command after confirming the plan.

[flyingrobots]

Confirmed from scripts/v18-to-v19/V18MigrationCommand.ts: v19.0.0 without --apply does a full planV18ToV19Migration + prepareV18MigrationScratch, returns verified-dry-run, then deletes the prepared scratch state in finally. A later --apply repeats planning, scratch construction, and scratch verification before the necessary refreshed-plan/compare-and-swap finalization. This is not a cheap preview; it duplicates the expensive work. Fix the normal interactive path to confirm and continue in one invocation. Keep a full non-finalizing rehearsal only behind explicit --dry-run, and document that a deliberately separate rehearsal/apply pair repeats work unless resumable scratch is introduced.