Reopening a file-reader session: re-resolve every name instead of assuming IDs stay stable

When a benchmark harness closes and reopens a data file mid-session (e.g. to grow a preloaded set in a reader mode that can't add items after the first load), don't reuse the numeric handles/IDs from the previous open.

The review fix that worked: - After each reopen, re-resolve every preloaded and requested name against the fresh name tree. - Compare each new ID with the old one, and stop with an explicit error ('reopen id mismatch: <name>') if any differs. Never silently remap. - Count the reopen and re-resolve cost inside the step that triggered it, so the timing stays honest. - Back it with a per-step answer hash checked against a reference arm, so a wrong mapping shows up as a hash mismatch even if the ID check is somehow bypassed.

Also handy: when adding a 'hash version must be vN' guard to a results checker, treat a missing version field as the legacy version, so older builds that never emitted the field still pass.