Task: Read the engine log with one parser

One parser in ores.ore reads the engine's log, and every consumer of the log reads it through that parser.

• ore_log_parser and its tests are gone.
• The compute node's log publisher reads engine_log_event, and the rows it publishes are unchanged.
• One suite covers both log.txt and log_structured.json.

engine_log already reads both logs, but it keeps less than its two clients read from the old parser, so it gains the rest of what the engine states on a line:

• the severity word as the engine wrote it, because the telemetry publisher forwards the engine's own level names and must keep sending the same ones;
• the location in parentheses, which the publisher sends as the entry's component;
• the time the engine stated, as a value, so no client parses the engine's timestamp again;
• whether the line stated the engine's fields at all. Both clients today read only lines the old parser recognised, and a line that is only text must not become a telemetry row or an error.

The verdict also carries a hand-written reader of the structured message: it searches the line for name=/=value pairs to name the trade or the curve. The event already states the subject and the fields, so the verdict reads those, and the search goes.

Then the old parser, its header and its suite are deleted. Its cases are not dropped: the level mapping, the memory report, the microsecond scaling and the refusal of a line without the engine's shape move to the engine log's suite, which is the one suite that covers both logs.

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.

The engine's log has one reader. ore_log_parser, its header and its 18-case suite are deleted, and its two clients read engine_log:

• the compute node's log publisher, which still sends the same entries under the same telemetry level names: the engine's own level word is kept on the event for exactly that translation, and a line the engine did not write in its own shape is still not forwarded;
• the run verdict, which also loses its hand-written search of the structured message for tradeId=/=curveId pairs. It asks the event for those fields now, so the JSON is read in one place.

engine_log gained what those clients read from the old parser and it did not keep: the level word, the location that logged the line, the time as a value, and whether the line stated the engine's fields at all. Two faults surfaced on the way: a structured message with no category was downgraded to notice, and the verdict's own fixture stated its sub-fields in a shape the engine never writes. Both are fixed.

One break on main is fixed here because it stopped these suites from building: the synthetic trade writer assigned a double into the decimal type that carries a basket constituent's initial price. A parallel environment landed the same fix as c18fc190ad, so this one is redundant history.

The review of this task found four defects in what it shipped and several clean-ups, all answered in one later PR: the reader stripped the spaces after the separator, a structured record without a category reached the store with an empty severity, the location could be read from a parenthesis inside the message, and the level table was duplicated in the wrapper with no test. The line is now read once, in the engine's order, and the level table lives with the severity vocabulary it translates.