v0.4.2 — where those fifteen rows actually came from

A follow-up to 0.4.1, which fixed a dropped flag but left the wrong attribution
in place. Full detail in
CHANGELOG.md.

Fixed

• A run reported what it reached and nothing about how it was set up, so fifteen recorded rows attributed themselves to the wrong lag budget. Every bench/results/*.json written from a MethodPolicy port pairs a cells list with a hand-typed config block; the cells were transcribed from the line standard_main prints, which states results only. Fifteen blocks recorded async_ratio: 2 for runs that took run_port's default of 1, and the attribution named bench.candidate_methods as the source.

  It was not. That harness has no --staleness and never passes staleness= to run_port, so every run through it is guarded — and all fifteen blocks record full. The transcribed line is what produced them, and that is checkable rather than argued: it formats qualities at .3f, seconds at .1f and calls as an int, and across all 45 cells not one value carries more precision, while the one file bench.candidate_methods did write has 198 of 198 wall/engine values at full float precision. Those files now record 1, with a note, and the eleven Run it commands pass --async-ratio 1.

• run_port records staleness in framework — the one setting a run could not state about itself, and the one that made those blocks impossible to attribute either way.

Added

• examples._method_runner.run_config and the config: line. A live run prints its resolved configuration as one JSON object, in the key names those results blocks already use, so a block is copied out of a run instead of remembered about it.
• tests/test_results_provenance.py keeps the forensic invariant executable: a future results file whose cells carry more precision than that print line came from somewhere else, and its config block cannot be read as describing a command-line run.