tables: JSON map key identity for padded and decimal spellings, and the prefix control's blade (#614)

[rowan-claude]

Closes #614.

Stella's three probes from the #607 re-run, red first in both engines, then one
rule each at the point the defect entered; and the prefix control repaired so
the branches it walks out through establish the defect it names.

What lands

The key is the spelling and nothing around it. Both key readers walked the
token with the walk that skips whitespace and comments. That is right BETWEEN
tokens and wrong INSIDE one: the walk consumed the padding, the "did the number
end at the token's end" check then passed, and the digit path was handed the
padded bytes. The walk now begins at the token's first byte, so a padded
spelling is not a JSON number at all and is malformed on the terms §16.2 gives
1-2, with the read stopping where §16.1 stops it.

Nothing on a KEY's path is a double. The one checked interpretation (#607's
C7) read a token carrying a fraction or an exponent through strtod /
ParseFloat, so a 53-bit mantissa decided the identity of a 64-bit key. A key's
digits are now read where they stand with the decimal exponent moving the point
-- the same normalization the wide kinds already use, ParseWide and
TableJsonReadWide, over one 64-bit lane. A zero fraction is the integer it
spells at every magnitude the kind holds.

The exact reader is the KEY path's and no other's. It lives in
TableJsonInterpretExact / interpretIntegerExact, beside the interpretation
the FIELD path keeps: TableJsonInterpret / interpretInteger, unchanged, with
the double and with finite. That split is the whole of the decision in
silence 2 below. A key is an IDENTITY, so two spellings a mantissa cannot tell
apart are two keys and the reference may rule alone; a field's value is a
quantity under a clamp, read the same way by the C, Go and Rust ports over the
same texts, and moving it moves four readers at once.

Engines: internal/codegen/cpptable/json.go (TableJsonMapKeyValue,
TableJsonInterpretExact) and internal/tabletext/read.go (placeMapKey,
interpretIntegerExact). No other backend carries a map key in JSON.

Red first

The gates are the two that already hold §16.2's map key rule: the C++
reference's map gate and the tool's own. Commit a9137b9 is the probes alone.

FAIL test/tables/maps_main.cpp:1088: !EdgeRowFromJson( eb, t, (int64_t) strlen( t ), &r )
FAIL test/tables/maps_main.cpp:1089: r.malformed
FAIL test/tables/maps_main.cpp:1108: eb.GetRoot()->ids.count = 1, want 2
FAIL test/tables/maps_main.cpp:1109: r.duplicate = 1, want 0
FAIL test/tables/maps_main.cpp:1113: EdgeRowIdsFind( eb.arena, eb.GetRoot()->ids, 9007199254740993ull ) != NULL
FAIL test/tables/maps_main.cpp:1128: r.kind_mismatch = 1, want 0
FAIL test/tables/maps_main.cpp:1130: r.duplicate = 0, want 1
FAIL test/tables/maps_main.cpp:1133: item->count = 1, want 2

8 map check(s) failed

maps_test.go:193: a padded key is not a JSON number: the read must stop,
    got {Unknown:0 KindMismatch:0 Clamped:0 Duplicate:1 Malformed:false}
maps_test.go:226: two keys 2^53 apart are two keys: {Duplicate:1}
maps_test.go:234: expected 2 entries, got 1
maps_test.go:257: the decimal spelling of UINT64_MAX is a key the kind holds:
    {KindMismatch:1 Duplicate:0}

The padded key parted the two engines, which is the sharpest reading of the
defect: the tool's byte arithmetic made " 2" the key 2402, colliding with
the literal 2402 beside it, while the reference's saturated and dropped the
entry as kind_mismatch. Neither is the page's answer, and one rule cannot
produce two.

Green after, both engines, on the same rows.

The FIELD path does not move, and here is the measurement

The exact reader reached every integer field in an earlier revision of this
branch, which parted the reference from the ports on a general path. It is now
the key path's alone, and the field path is byte-for-byte what origin/main
produces. Measured on tabledemo RootConfig through the C++ reference and
through the tool, main compiled into a scratch tree for the baseline:

token, in this field	main (reference and tool)	this branch (reference and tool)
1e309 in badge uint8	0, kind_mismatch=1	0, kind_mismatch=1
-1e309 in timestamp int64	0, kind_mismatch=1	0, kind_mismatch=1
9007199254740993.0 in epoch uint64	9007199254740992	9007199254740992
18446744073709551615 in epoch uint64	18446744073709551615, clamped=0	18446744073709551615, clamped=0
18446744073709551615.0 in epoch uint64	18446744073709551615, clamped=1	18446744073709551615, clamped=1
2.5 in badge uint8	0, kind_mismatch=1	0, kind_mismatch=1
1e400 in precision float64	0, kind_mismatch=1	0, kind_mismatch=1

Every cell equals main's, in both engines, and the four rows the earlier
revision moved (1e309 to 255 with clamped=2, -1e309 to INT64_MIN with
clamped=2, the 2^53 spelling to ...993, the decimal UINT64_MAX to clamped=0)
are back where the ports have them. TestRejectedRepeatKeepsTheFirstValue takes
its original 1e309 token back with them, and
TestAnIntegerFieldReadsItsTokenThroughTheFloat beside it pins four of the
table's rows against the ports, so a future re-unification has to go red first.

schema pack says the same thing at the CLI. A one-profile tree whose
0-ace.json is { "badge": 1e309, "epoch": 9007199254740993.0 }, packed by this
branch and by main's compiler:

report: unknown 0, kind_mismatch 1, widened 0, clamped 0, duplicate 0, malformed false
schema: the report is not silent -- pass --tolerate to accept it

Identical from both, and with --tolerate the 63 wire bytes compare equal.

The KEY rows are unmoved by the restoration: the map gate is green in both
engines, a padded key is still malformed, two keys 2^53 apart are still two
keys, and the decimal spelling of UINT64_MAX is still a key.

The controls

tables-json-clamp-prefix-negative-control had two of four branches spelling
return 0 -- success, "red" -- over a run that observed no prefix at all. Both
now fail. Quoted against a walker sabotaged to refuse the read, and against one
whose clamp counter is wrong as well as its bytes:

---- readfail / old control ----
clamp prefix negative control: the sabotaged walker would not read at all: red
exit=0
---- readfail / new control ----
FAIL clamp prefix negative control: the walker would not read this text at
      all, so the clamp was never reached and the stored bytes say nothing.
      A failed read does not establish the defect this control names.
exit=1
---- countfail / old control ----
clamp prefix negative control: the clamp went uncounted as well: red, but for the wrong reason
exit=0
---- countfail / new control ----
FAIL clamp prefix negative control: the read counted 3 clamps where the
      text spells exactly one, so this run is not the one-clamp read the
      control reads bytes out of.
exit=1

The target now runs the control BOTH ways, because a binary that only ever meets
the sabotage cannot show it has a blade. Under the sabotage it must see the
wrong bytes; against the honest walker it must find nothing to see:

./build/schema_test_json_clamp_prefix_negative
clamp prefix negative control: the scan resumed past the code point that did not fit,
      storing 16 bytes the text never spelled in that order: red, as required

build/schema_test_json_clamp_prefix_honest
FAIL clamp prefix negative control: a walker whose scan resumes after an
      over-long code point still stored the prefix.
exit=1

negative control: the clamp prefix control sees the defect under the sabotage and nothing without it

The fifteen tables-maps-*-negative-control sabotages are unchanged and stay
green, keydomain and keyidentity included -- the two nearest this diff.

The page, and what it left to be decided

§16.2 settles the map key rule in one clause: an integer key "is its decimal
spelling, quoted, read by the integer rule above and by nothing else, so a token
that rule calls malformed makes the key malformed and one with a fractional
value or out of the key kind's range drops its entry as kind_mismatch". Three
things the page does not spell in those words, decided here on reduce-cases and
listed for the owner:

1. Whitespace inside a key. The page never says the word. The integer rule
   says "the token grammar is RFC 8259's", and RFC 8259's number production has
   no whitespace in it, so a padded spelling is "a token that is not a JSON
   number at all" and the page's own answer for that is malformed. Decided:
   malformed, the read stops. The alternative -- trim and accept -- gives one
   entry two names, which is the identity corruption the clause exists to
   prevent.

2. Whether a FIELD reads its token the way a KEY now does. Not decided here,
   and unchanged by this PR. The exact reader is the key path's alone. On the
   field path the reference and the tool still read a fractional or exponent
   spelling through the double, exactly as ctable/json.go:1349-1382,
   gotable/json.go:1392-1430 and rusttable/runtime.go:2150-2190 do, so
   9007199254740993.0 in a uint64 lands ...992 in all four and 1e309 in a
   uint8 is kind_mismatch in all four. That is the reference agreeing with
   its ports, not a defect this PR leaves standing: the reading is one the
   OWNER settles for all nine at once, and it is put to him in Owner ruling wanted: exact integer interpretation for integer FIELDS in the text form, across the nine (1e309, decimal spellings at 2^53, decimal UINT64_MAX) #629 with the
   measured table. Under either answer there the nine move together, and this
   PR moves none of them.

3. Where these rows live. The task suggested json-hostile rows. The
   mapdemo unit is not a conformance unit -- no unit in MANIFEST.txt declares
   a map -- so the probes went to the two JSON walk gates that already hold
   §16.2's key rule (test/tables/maps_main.cpp,
   test/conformance/harness/maps_test.go), which is where tables: the C++ JSON walker's map keys, placement failures and one numeric interpretation (#566) #607 put the rows
   these extend. Admitting mapdemo to the conformance corpus is a larger,
   separate move and is the owner's to want.

#609's retained decision is untouched and now PINNED in both engines rather than
held by code alone: an integer key past the scan's 255-byte buffer drops as
kind_mismatch, and the row is built so length alone cannot carry it. The key is
256 bytes and spells the integer 1, a value the kind holds, and the prefix that
fits the buffer spells 1 as well -- so a read that truncated would merge it
into the entry beside it and call two keys one. At 255 bytes the same text reads
the key and counts a duplicate, which is what makes the row a reading of the
bound and not of the length. EdgeRow.names' identity row is green beside it.

The goldens

33 files, one class of change: 32 *Table.cpp under testdata/golden and
generated/bench/tables/cpp/BenchTableTable.cpp, which is the same walk in the
tables bench corpus. Every one is a translation unit carrying the JSON walk
(§13.5 puts the walk in the .cpp, which is why no header moved), and the diff in
each is these lines and nothing else. It has exactly two shapes:

25 files   +80 -3    the exact reader added beside the field's, and the header
                     comment that says which path each is for
 8 files   +91 -5    the same, plus the map key call site: the walk that starts
                     at the token's first byte, and TableJsonInterpretExact

The eight are the map-bearing units (tables/maps, tables/lists). No wire
golden, no id, no dump, no header moved. bench/LOCK records the bench corpus as
under no locked prefix; the prefix list is empty (lifted 2026-09-05) and the
standing gate names the C/C++ PACKET emitters, which this diff does not touch.

origin/main, merged

origin/main moved twice under this branch and both are merged in, never
rebased: a0f32ed (#624, #615) and 5e04d3f (#627, docs). make update-goldens
after each merge moved nothing, so the merge result and the regenerated tree
agree byte for byte, and no golden was touched by hand.

make test, on the bench

make test whole, on this Mac Studio, on the merged head. It stops at
build-conformance-cs with /bin/sh: dotnet: command not found -- the absent
toolchain, not a result. go test ./... is clean.

Toolchain absences on this bench (#599): no node, dart, java, elixir or dotnet,
so the JS, Dart, Java and Elixir legs skip silently and the C# legs stop. CI has
all of them, and its twenty checks are green on 6f6be17.

Twenty FAILED lines stand in the log before the stop and every one is a
negative control reporting its own red, each sitting beside its
negative control: ... turns ... RED line. No non-toolchain failure anywhere
in the run. The gates this PR touches, green in it:

maps: all checks passed (docs/SPEC-TABLES.md §2.8)          (plain and asan)
tables map-walk gate: one map half, byte-identical in 3 map-bearing .cpp files
negative control: keyidentity turns the MAP GATE red — 2 failures
negative control: keydomain turns the MAP GATE red — 4 failures

The four targets named on this work were then run on their own, past the stop,
and are green: tables-maps, tables-json-map-walk,
tables-json-clamp-prefix-negative-control, and
tables-maps-negative-controls, whose fifteen sabotages each turn the map gate
red as required, keyidentity and keydomain among them.

negative control: the clamp prefix control sees the defect under the sabotage
                  and nothing without it