Restack branches with cascading server-side rebases #50

Outcome

One operation rebases a stack from the trunk upward, pausing on conflict with durable recovery state, and moving every branch ref through one atomic batch.

Context

docs/stacked-prs.md sections 5.4–5.5 and 12 define the algorithm. Follow the house background-work idioms: an outbox table drained by a polling GenServer (the repository provisioner shape) or a Horde singleton for the long loop.

Acceptance criteria

• stack_operations rows record kind, state, target position, expected stack version, idempotency key, request, snapshot, planned result, and error. States include pending, running, waiting_for_conflict_resolution, succeeded, partially_succeeded, failed, cancelled.
• The waterfall walks bottom to top: verify the live branch still equals the observed head, replay commits after the stored boundary onto the new parent, plan ref updates with old/new OIDs, then apply every update through the batch-CAS primitive in one transaction.
• A conflict persists the workspace: old boundary, old head, proposed parent, in-flight commit, conflict paths, prior step results. Continue and abort endpoints resume or roll back from that state; the server re-verifies branch heads before applying.
• New commits build under temporary internal refs before any public branch moves.
• Commit signature policy is explicit: unsigned server restacks, forge-signed, or local-only. Document the choice in the issue's delivery notes.
• Each completed operation emits PR synchronize and stack rebase events.

Verification

Domain tests for clean runs, mid-stack conflicts, concurrent push during rebase (CAS failure preserves the user branch), and crash-and-resume recovery. Run mix precommit.

Dependencies

Git primitives (#46), stack schema (#47), stack API (#48).