tdbg: add per-schedule V1/V2/sentinel status check to schedule migrate status

[davidporter-id-au]

What

Adds a --schedule-id flag to tdbg schedule migrate status. When set, it looks up one specific schedule instead of the namespace-wide V1-vs-V2 counts, and reports whether that schedule is currently V1 (workflow-backed), V2 (CHASM), or caught in a migration sentinel state.

Why

During schedule migration triage, an operator often needs to know the status of one specific schedule, not aggregate counts. There was no way to answer that without manually poking execution describe and reasoning about CHASM node internals by hand.

How it works

It always probes both sides — the V1 workflow ID (temporal-sys-scheduler:<id>) and the V2/CHASM business ID (<id>) — via the same DescribeMutableState RPC that tdbg execution describe uses, regardless of which ID form was passed in. It deliberately does not short-circuit based on the input's shape (e.g. its prefix) without confirming against the server — an unconfirmed inference is confusing/untrustworthy in a diagnostic tool.

This lets it flag both kinds of migration sentinel:

• a CHASM-side sentinel Scheduler component reserving the ID during a V1→V2 migration
• a V1-side DummyWorkflow reserving the workflow ID during a V2→V1 rollback

Output leads with a plain-language headline describing the schedule's current, authoritative form (written for someone with no prior knowledge of the V1/V2 migration internals), followed by a note about any sentinel found on the other side, a details table of both sides' raw status, and the exact execution describe invocations to inspect each side further.

Example output (V2→V1 rollback in flight)

Schedule "foo" is a V2 (CHASM) schedule.
Additionally, a placeholder ("sentinel") V1 workflow exists at workflow ID "temporal-sys-scheduler:foo",
reserving that ID while a V2→V1 rollback is in progress. This is expected during rollback and requires no action.

Details:
  V1 (workflow-backed)  [workflow ID temporal-sys-scheduler:foo]: sentinel (V2→V1 rollback placeholder)
  V2 (CHASM)            [business ID foo]: genuine

Inspect further:
  V1: tdbg execution describe --workflow-id temporal-sys-scheduler:foo -n <namespace>
  V2: tdbg execution describe --workflow-id foo --archetype scheduler.scheduler -n <namespace>

Testing

• go test ./tools/tdbg/... -run TestScheduleStatus -v — new tests cover: prefixed input, genuine V1, genuine V2, V1 genuine + CHASM sentinel, V1 sentinel + genuine V2, not-found on both sides, and an unexpected/inconsistent-state fallback. Existing aggregate-count tests are unaffected.
• go build ./tools/..., go vet ./tools/tdbg/...
• Manually checked tdbg schedule migrate status --help output.

🤖 Generated with Claude Code