fix(ladder): normalize locked tranche amounts before netting #890

Summary

Locked ladder netting sums stored tranche amounts without using their persisted amount basis and planning rate. Valid native commitment amounts and verified on-demand-equivalent amounts cannot be added directly.

Current behavior and reproduction

Through the real PostgreSQL store, seed one verified OD tranche of 15 and one native commitment tranche of 20 with stored rate 1/2. PlanAndSaveLadderRun passes 35 to the existing aggregate planner; the correct netted OD amount is 55. A synthetic actual-planner fixture with target 10, OD 1 and native 2 at rate 1/2 places 7 instead of 5. A selected historical row with unknown basis also permits planning despite unproven units. These are constructed regression fixtures, not claims about observed live purchases.

Expected behavior and proposed fix

In internal/config/store_postgres_ladder_lock.go, preserve the config lock and two ordered reads, but load exact amounts and persisted provenance. Count verified OD directly and convert native amounts only with their own stored rate. Reject unknown or invalid provenance before building or inserting a run. Preserve fired-any-age, strict scheduled grace and strict settled-anchor behavior, including intentional duplicate observations during completion.

Reuse the existing validator in internal/config/ladder_provenance.go and pass one conservatively rounded OD total to the existing planner. Keep SDK pins, provider forecasts, native writer activation and the old allocator's aggregate-only scope unchanged. Verify real store-to-planner persistence, selection boundaries, lock concurrency, unknown refusal and meaningful parent/mutation failures.

References and severity

Provenance persistence: #885 / #886. Broader ladder integration: #631. This differs from #118's lifecycle-status problem.

Severity: high. Mixing commitment and OD units can overstate the remaining purchase gap when mixed-basis rows are present.