fix(vcd): left-extend compact vector values and keep final replay timestamp

[0xaef]

Problem

parse_input_vcd misreads compact binary VCD vector values and drops the final timestamp.

1. Compact values are not left-extended. IEEE 1364 §18.2 allows a binary vector value to be shorter than the declared width. It must be left-extended: with 0 for a leading 0 or 1, and with x or z for a leading x or z. The parser enumerated the compact payload from position 0, but match_vcd_inputs maps position 0 to the declared MSB. So b1 on a 28-bit input was read as 0x8000000 instead of 0x0000001. Bits not covered by a short value also kept their previously driven values.
2. The final settled timestamp is missing. In the regression fixture the last edge, at #15, is omitted and the last reported timestamp is 5. A later input change could also be assigned to an earlier output sample.

The GPU path and the internal CPU check share this parser, so they agree with each other while both being wrong. This showed up when we compared against an independent RTL simulator.

Fix

• Expand each value to its declared width before mapping MSB-first.
• Settle each timestamp before accepting later inputs, and flush the final one.
• Update the CLI call site.

Tests

New regression tests use the real NetlistDB / AIG / match_vcd_inputs / parse_input_vcd path, with no partitioner or GPU, and an inline 28-bit fixture:

• compact_payload_keeps_numeric_value: b1 on [27:0] must equal 1.
• final_clock_edge_has_output_timestamp: the edge at #15 is present.
• replay_groups_do_not_advance_combinational_inputs: grouped input ordering.

Both bugs reproduce at de0be04. With this change, cargo test --lib passes 350/350 on macOS arm64.