Task: Fix the second value the parameter history test writes

The parameter history test writes two values ORE would accept, so it passes on a fresh database and proves the history read rather than a bypass of the value rules.

• The test writes a second value of the same kind as the first, and the second parses as the first does.
• The analytics core suite passes on a freshly recreated database.

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Every number this task claims about a tree, with the command that produced it and the commit it was measured at. A number without both is not a measurement, because a clean-up record describes a tree and trunk moves under a branch: a consumer count, a gate's component count and a suite's size all change with no code changing, and the reader of a bare number cannot tell which tree it came from. Where the raw output matters, put it in an evidence/ file beside the task and name that file in the Command column.

Manual QA scenarios (scaffolded via compass add test_scenario) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Finished. The test's second value is derived from the first by moving the number, so both values parse as the first does and ORE would read them. No production code changed and the guard is untouched.

The analytics core suite passes on a freshly recreated database: 76 cases, 496 assertions.