fix: retain fork checkpoints with direct history ancestry

[EItanya]

Forks omit inherited checkpoints because listing filters only by the instance that created them. A fork at C2 now lists C1 and C2 alongside its own checkpoints, excluding source-history boundaries after C2 and preserving each checkpoint's original provenance.

Store immutable parent-history and cutoff fields on agent_history, renamed from a2a_context to distinguish a history branch from its public A2A context ID. Keep the source-checkpoint reference on the instance for fork-request identity and runtime provenance. Forks continue copying bounded events and rebuilding private task projections at terminal task boundaries; ancestry traversal no longer depends on checkpoint rows. All schema changes are inline in migration 1 for the pre-release baseline.

Listing bounds candidates per history before combining the checkpoint-ID page. Retained histories protect inherited checkpoints and their snapshot Tags even after all related instances are deleted; there is currently no history garbage collection. Fork creation and deletion checks share a history lock, while deletions already in progress can finish or retry. Listing by a deleted instance's former ID still returns its locally created checkpoints.

Validation:

• PostgreSQL database suite and migration Up/Down tests, including every inline SQL prepare check, passed with the race detector.
• After rebasing onto main at 7125643c, the database, migration, A2A gateway, checkpoint-service, and instance-service suites passed with the race detector. The E2E package compiled successfully, and full Go lint reported zero issues.
• Coverage includes nested forks, source cutoffs, ownership, local/inherited/mixed pagination, ancestor deletion, retained snapshots, and deletion retries. An independent correctness review found no issues.
• The final listing query uses the source/history indexes in custom and generic PostgreSQL 18 plans. An isolated fixture with 100,000 checkpoints across 1,000 histories returned 50 inherited checkpoints in 0.25–0.4 ms; this is a synthetic plan check, not an application benchmark.
• The complete live E2E suite passed in CI at bc507cd9, including runtime collection after unforked checkpoint deletion and checkpoint retention after fork-instance deletion. That live E2E result predates the rebase; live E2E on the rebased branch is pending CI. The rebase preserves main's rejection of checkpoints during input-required or auth-required tasks.
• The separate migration-immutability check intentionally fails because migration 1 is the pre-release baseline; the guard is unchanged.