seals: ml_host_io_model gen_hash_verilog is stale after the gen-verilog assignment-target fix; coverage and spec-guards are red on master #11102

Part of the night-loop epic #11063. Master is red on two checks since #11094 merged: coverage (job "Every seal still describes its spec") and spec-guards (tools/check_seal_currency.py) both report one stale seal: .trinity/seals/ml_host_io_model.json holds gen_hash_verilog sealed=7ee920eef949 current=a8beaecd9847 while specs/ml/host_io_model.t27 is byte-identical. The spec did not move; the Verilog emitter did (gen-verilog no longer wraps an assignment target in $signed, #11094). Every open PR inherits the two reds.

Goal

The seal of specs/ml/host_io_model.t27 records the Verilog the compiler on master now emits, so coverage and spec-guards go green for every PR.

Requirements

• FR-001: The seal MUST be re-saved with the t27c built from current master, after t27c test-report specs/ml/host_io_model.t27 shows its tests passing with vacuous passes 0.
• FR-002: Only gen_hash_verilog of that seal MAY change; spec_hash and every other recorded hash stay as they are. If any other field moves, the PR must say why.
• FR-003: The Verilog difference MUST be read before sealing: the new output differs from the old only where an assignment target was wrapped in $signed.

Scenarios

• Given the re-saved seal, when python3 tools/check_seal_currency.py runs, then it prints STALE generated-code hash : 0 and exits 0.
• Given the same tree, when t27c seal specs/ml/host_io_model.t27 --verify runs, then it prints that all hashes MATCH.

Boundary

• .trinity/seals/ml_host_io_model.json

Success Criteria

• python3 tools/check_seal_currency.py exits 0 on the PR tree.
• The PR diff touches .trinity/seals/ml_host_io_model.json only, and only its gen_hash_verilog line (plus the timestamp field if the file keeps one).
• coverage and spec-guards are green on the PR.