Reclaim ended allocations without synthesizing outcomes and order limit updates

[ctfbruce]

Ended execution windows previously fabricated a terminal result and settled payments, while a timed-out destination update could still overwrite a newer limit at the executor. This change records local allocation reclamation independently and makes current peers acknowledge ordered allocation snapshots.

• Record an immutable reclamation timestamp after the existing window-plus-grace policy, release reservations by run identity, reject delayed reallocation and exclude reclaimed runs from restart restoration. Actual terminal evidence remains eligible under its original binding; cleanup does not replay work or settle payment.
• Advertise ordered snapshot support during the existing handshake, reject older revisions at application, and acknowledge only fully published limits. Keep one pending revision per existing session and reconcile it on heartbeat; allocation delivery failures are returned to the caller.
• Preserve legacy control compatibility. Legacy peers can allocate runs, but a live destination change records the admission cap and returns an actionable upgrade error instead of claiming ordered application.

Dispatcher schema 19 requires the existing operator-invoked database upgrade. API 1.14 adds optional allocation_reclaimed_at to recovery inspection. Reclamation is a local accounting fact: it neither proves remote traffic has stopped nor releases retained-work admission quotas.

Validation: focused dispatcher/executor regressions under -race -count=3, including replacement-session isolation; API destination compatibility and scheduler restoration tests; storage schema/client checks; dispatcher/executor vet. Independent source review found no outstanding correctness findings. Full candidate CI run 37004665121 passed all 16 jobs, including test, race, kernel, generated-file checks, packaged demo, compatibility and local deployment.

Refs #37, #44.