graph, store: reject grafts below the base subgraph's earliest_block

[rslowinski]

The bug

Graft::validate permits grafting at a block below the base subgraph's earliest_block_number. When that happens, the copy silently produces a destination with reset state for any entity whose live-at-graft version had been pruned from the base. This is most visible on heavily-updated mutable singletons: every sub-graft-block version of such an entity is a closed historical version, every closed historical version below the prune floor is eligible for pruning, so the live-at-graft version is gone, the copy (lower(block_range) <= graft_block) finds nothing for that entity, and the handler subsequently re-initialises it from defaults. Immutable entities and rarely-updated mutable entities (whose live-at-graft version is still open) are unaffected, so the corruption is selective and easy to miss in spot checks.

A structural fingerprint of an affected deployment: its earliest_block_number is strictly greater than its head/graft block. That state cannot arise from a correctly-performed graft; it's the inversion produced by copy_earliest_block propagating the parent's prune floor into a destination seeded at a block below it.

Reproduction (new tests)

graft_validate_rejects_below_prune_floor and graft_store_path_rejects_below_prune_floor capture the minimal repro against a fresh Postgres in ~1–2s:

1. Start with three test entities at blocks 0, 1, 2 (the default setup in graft.rs).
2. Update user 2 at block 3, closing its [1, 3) version (which was live at block 2).
3. Forward head to block 6, then prune with history_blocks=2 → earliest_block=4. This removes the closed user 2 [1, 3) and user 3 [1, 2).
4. Without this fix, grafting at block 2 succeeds, and the destination is missing user 2: its only surviving version [3, ) is excluded by the copy filter lower(block_range) <= 2. With this fix, the graft is rejected with an actionable error naming the prune floor.

Fix (3 commits)

1. graph, store: validate graft block against base subgraph's earliest_block — adds SubgraphStore::earliest_block_number, uses it in Graft::validate to reject sub-floor grafts at manifest validation time. Makes Graft::validate pub so tooling and tests can validate a graft directly without resolving a full UnvalidatedSubgraphManifest.

2. store: enforce graft prune-floor invariant in start_subgraph — defence in depth: a pre-copy check in DeploymentStore::start_subgraph catches callers that reach the store path without going through Graft::validate (graphman, custom tooling, test_store::create_subgraph). A post-copy check detects the prune-during-copy race that copy_earliest_block already warns about.

3. store: take the max of source and destination history_blocks during graft — secondary issue found in the same code path. Graft finalization currently overwrites the destination's history_blocks with the source's value unconditionally, silently downgrading prune: never children to whatever retention the parent used. Use max(src, dst) instead.

Related upstream work

#6384 added the analogous check on the graphman copy admin path. This PR extends the same invariant to the deployment graft path (Graft::validate + start_subgraph). The two PRs are complementary — neither makes the other redundant.

Tests

Three new regression tests in store/test-store/tests/postgres/graft.rs:

• graft_validate_rejects_below_prune_floor — manifest-level check.
• graft_store_path_rejects_below_prune_floor — store-level check (also confirms graft at the floor is still accepted).
• graft_history_blocks_takes_max_of_parent_and_child — secondary fix.

Existing graft, prune, copy, on_sync tests are unchanged and green. cargo fmt --all -- --check, cargo check --workspace --tests, and cargo check --release --workspace all pass on rustc 1.91.

Notes for the reviewer

• Graft::validate becomes pub. The struct and the validation error type were already public; making the function callable directly from tooling/tests removes the need to resolve a full manifest in those callers. Happy to use a different approach (e.g. a thin pub wrapper, or a test-only re-export) if you'd prefer the function itself to stay crate-private.

• The history_blocks change to max() is a deliberate behaviour change. The previous overwrite was internally consistent if you assumed destinations should match their source's retention, but it silently overrides an explicit prune: never on the destination. max() honours both constraints simultaneously. Easy to split into its own PR if you'd rather discuss it independently from the prune-floor fix.

• Does this recover existing subgraphs already corrupted by this bug? No — re-indexing is the remediation. The fix prevents new occurrences only.