Persist full merge train queue records

[cbusillo]

Objective

Persist merge train queue entries and train state as Launchplane-owned records. The current queue is derived from live GitHub labels during each run; a full train needs durable position, status, validation, and blocker state so it can advance multiple PRs over time without forgetting why a PR is waiting.

Finish Line

Persist full merge train queue records

Current Status

State: Done for the initial storage foundation via PR #608, merged to main at 4aca673 and deployed. Batch candidate and landing-plan record contracts, filesystem/Postgres stores, import path, migration, and round-trip tests are in place.
Next action: Use #604/#605 to write these records from the batch validation service flow.
Blocked by: None for the storage foundation.
Last verified: Main CI, Security, CodeQL, and Deploy Launchplane succeeded for 4aca673 on May 14, 2026.

Scope

• In: queue entry records, train state records, migrations, filesystem/postgres store methods, import/copy support, read models, and tests.
• Out: GitHub ref creation, speculative checks, or live merge mutations.

Acceptance Criteria

• Queue entries include repository, base branch, PR number, queue position, source label/event, observed head SHA, status, blocker, and timestamps.
• Train state records identify the active train generation and current ordered entries.
• Entries can be superseded, dequeued, blocked, validating, ready, merged, or cancelled without losing audit history.
• Idempotency prevents duplicate queue entries for the same PR/head when enqueue events repeat.
• Read models summarize train state without exposing secrets or provider-only internals.

Relationships

• Blocked by the full-train semantics issue.
• Blocks scheduler, feedback, and speculative validation work.

Validation

• Migration upgrade/downgrade tests.
• Filesystem and Postgres store tests.
• Service contract tests for enqueue/dequeue/read operations.

Decisions

• Runtime train state belongs in DB-backed Launchplane records, not checked-in config.

Open Questions

• Should labels remain the only enqueue source, or should the operator UI/API also enqueue directly?