state: a rehydrated run sees its data in the order the live run built it (#871)

[Masterplanner25]

Closes #871.

The defect

The graph snapshot and both stores persisted state with sort_keys=True, so a
map a program built as {web, code, data} came back {code, data, web} after a
cross-process resume:

in-process : {"web": 1, "code": 2, "data": 3}
rehydrated : {"code": 2, "data": 3, "web": 1}
control    : {"web": 1, "code": 2, "data": 3}   # same program, no resume

Same content, different string — so anything derived from it differed across a
restart: a draft, a hash, an @exactly_once key. That last one is how the
reporting project found it, an idempotent publish re-firing on a rehydrated
replay of an identical draft.

JSON objects preserve order and json.load round-trips it, so nothing but the
sort was destroying it.

Where it was, and where it stays

Six sort_keys sites, three kinds:

Kind	Sites	Change
Persisted state	graph snapshot, local store, SQLite columns	sort removed
Identity	compute_action_id, bytecode cache key	unchanged
Display	nodus graph output, dependency graph file	unchanged

The distinction is reported vs compared. Persisted state is read back and
handed to a program, so it must come back as it went in. An identity is hashed,
and there two equal maps built in different orders have to produce one answer.

The regression test asserts both directions — removing the sort where it is
load-bearing has to fail too. Without that half this reads as "sorting is always
wrong", which is how the next person removes the wrong one.

Scope: one site or four?

The graph snapshot alone fixes the reported symptom — step results and state
cells both round-trip after that one line. I fixed the stores as well, because
the store keeps a second copy of workflow_state and nodus workflow inspect prints it, so a user was seeing sorted keys while the program saw
insertion order. Measured before and after:

before:  store workflow_state: {"cfg": {"apple": 2.0, "mango": 3.0, "zebra": 1.0}}
after:   store workflow_state: {"cfg": {"zebra": 1.0, "apple": 2.0, "mango": 3.0}}

_state_json names the rule once rather than splitting guest data from
bookkeeping field by field: claim and wait are mostly bookkeeping, but wait
carries the guest's payload, and a hand-maintained "may reorder / may not" list
is the kind that drifts. Nothing there is content-addressed, compared as a
string, or indexed on, so there is nothing to trade away.

No canonical mode added to std:json

That was the issue's alternative fix. With order round-tripping it is not needed
here: @exactly_once already canonicalises internally, so a key derived from a
step result is now stable across a restart without the caller doing anything.
Said so in the changelog rather than leaving it as an open question.

Tests

tests/test_rehydrated_key_order.py, 8 tests. Three per-decision neuters,
restoring from saved byte copies:

BASELINE (fixed tree)                          8 passed
graph snapshot sorts again (the 5.14 rule)     RED   3 failed
store serialization sorts again                RED   2 failed
the effect action id STOPS canonicalising      RED   1 failed
RESTORED                                       8 passed

The third is the inverse direction, and it is the one that matters for the next
reader.

Two test-authoring bugs of mine, both caught by a test failing for the wrong
reason — worth naming because both would have produced a green test that
checked nothing:

• The first store assertion read the repo-root store and took list_runs()[-1]
  — a stranger's record among ~400. It looks its own run up by id now, and the
  store-level check builds its stores in a tempdir.
• Parametrising the harness by NODUS_WORKFLOW_STORE_BACKEND does not work:
  the variable is read when the default runner is built, and that runner is
  cached per process, so setting it in setUp after another test built one
  silently reads a store it is not writing to. The tests passed alone and failed
  in the file. The snapshot round trip is backend-independent, so one run covers
  it; the store serialization is covered directly instead.

Checks

• targeted set (rehydration, persistence, resume, state policies, store
  lifecycle, migration, effects, determinism boundary): 125 passed
• ruff clean · mypy src/nodus/ clean — note it does not cover
  src/nodus_lang_workflow/, so CI is the only type check for that half
• nodus_gate --all green, all ten phases (BUG-869: the local store's age filter hides waiting runs from listing, migration, rehydration and the #174 warning #869's lesson)
• release probes 130/130 (BUG-870: #482 removed reject-and-revise with no replacement, and the CHANGELOG misstates what the old behaviour did #870's lesson — --all does not run them)

🤖 Generated with Claude Code