[SV3 §3.3 / LRM 5.7.1] Add semantic and negative integer-literal coverage

## Scope

This issue covers only integer and logic literal conformance:

- IEEE Std 1364-2005 §3.5.1, **Integer constants**.
- IEEE Std 1800-2005 §3.3, **Integer and logic literals**.
- The repository's later-LRM tag **5.7.1, Integer literal constants**.

Parsing/elaboration, process scheduling, `initial` execution semantics, real literals, strings, time literals, arrays, and structures are outside this issue except where simulation is used only as the observation mechanism.

## Audited baseline

Audit point: [chipsalliance/sv-tests `master` at `c4229f3`](https://github.com/chipsalliance/sv-tests/tree/c4229f3bd5220e6d3ba8f390e5d09c87e462e9c7).

The repository README requires a minimal test for one directly tagged feature. At this audit point:

- 64 committed files carry tag `5.7.1`: 9 under `tests/chapter-5` and 55 under `tests/generic/number`.
- 62 are positive tests and 2 are negative tests.
- None specifies simulation mode.
- None emits a `:assert:` value oracle.
- Missing `:type:` defaults to `parsing elaboration` in [`tools/runner`](https://github.com/chipsalliance/sv-tests/blob/c4229f3bd5220e6d3ba8f390e5d09c87e462e9c7/tools/runner#L152-L162).
- `tests/chapter-5/5.7.1--integers-token.sv` declares an `integer` variable but contains no integer literal.
- The 55 generic number files are parser examples and are co-tagged `5.7.1` and `5.7.2`, although they contain no real literals.
- The two direct negative cases cover only `8'd-6` and the missing-base form `4af`.

Generated third-party wrappers tagged only by their imported suite are not attributable §5.7.1 coverage and should not replace direct clause tests.

## Standards basis

IEEE 1364-2005 §3.5.1 requires, among other points:

- a nonzero size specifying the exact literal width;
- truncation from the left when the written value exceeds that size;
- zero, X, or Z left-padding when the written value is shorter;
- simple decimals to be signed and based literals to be unsigned unless `s` is present;
- `s` to change interpretation, not the specified bit pattern;
- negative numbers to use two's-complement representation;
- X/Z to contribute 4, 3, or 1 bits per hexadecimal, octal, or binary digit;
- an unsized number to contain at least 32 bits;
- `?` to be an alternative spelling of Z;
- decimal X/Z/? to be legal only as a single digit;
- underscores to be ignored but not accepted as the first character;
- sized negative and sized signed values to sign-extend regardless of destination signedness;
- no whitespace between the apostrophe and base-format character.

IEEE 1800-2005 §3.3 inherits Verilog signedness, truncation, and left-extension rules and adds `'0`, `'1`, `'x`, and `'z`; in a self-determined context these have width 1 and are unsigned.

## Existing incidental checks do not close this gap

The whole-repository cross-check found a few tests under other feature tags:

- `11.4.1--assignment-sim.sv` checks the basic value of `4'd12`.
- `11.7--signed_func-sim.sv` checks `$signed(4'b1000)` sign-extension.
- `11.7--unsigned_func-sim.sv` checks `$unsigned(-4)`.
- `20.9--isunknown.sv` observes binary X/Z.
- `20.9--countbits.sv` uses `'0/'1/'x/'z` as one-bit control arguments.

These target assignment, conversion, and system-function behavior; they do not directly or comprehensively establish §5.7.1 conformance. In particular, the earlier broad claim that *no negative literal value is checked anywhere* is narrowed here: `$unsigned(-4)` is incidental coverage, but the sized negative literal rules and the standard examples remain unchecked.

## Required positive semantic coverage

Add direct `5.7.1` simulation tests for:

- [ ] Unsized decimal width: verify `$bits(1) >= 32`, without assuming exactly 32.
- [ ] Literal-size truncation: for example, verify `4'h1f === 4'hf`.
- [ ] Zero/X/Z left-extension, including the existing examples `'h3x`, `'hz3`, `'h5`, `'hx`, and `'hz`.
- [ ] Sign-extension into both signed and unsigned wider destinations.
- [ ] Simple-decimal signedness versus unsigned based-literal signedness.
- [ ] Sized negative bit patterns, including `-8'd6 === 8'hfa` and `-4'sd15 === 4'h1`.
- [ ] The `s` designator: identical source-width bit pattern but different signed interpretation/extension.
- [ ] X and Z expansion across hexadecimal, octal, and binary digits.
- [ ] `?` equivalence to Z across decimal, hexadecimal, octal, and binary forms.
- [ ] Direct `'0/'1/'x/'z` filling of multiple destination widths, including a width greater than 32.
- [ ] Self-determined width and unsignedness; for example, contrast direct `dst = '1` with `dst = {'1}`.
- [ ] Value equivalence of underscored and non-underscored decimal, binary, octal, and hexadecimal forms.

Four-state expectations should use case equality or a deterministic formatted-string comparison so X and Z cannot be silently coerced.

## Required negative coverage

Add separate expected-failure tests for:

- [ ] Zero size, such as `0'b1`.
- [ ] Illegal digit for each radix, such as `4'b2`, `4'o8`, `4'hg`, and `4'dA`.
- [ ] Whitespace between apostrophe and base-format character, such as `8' hff`.
- [ ] A leading underscore in the value token, such as `8'h_ff`.
- [ ] Multi-digit decimal tokens containing X, Z, or ?, such as `8'dx0`, `8'd1z`, and `8'd??`.

The imported-Icarus generator currently explicitly excludes its zero-sized-constant case (`br_gh60a`), so a native standard-tagged negative case is still required.

## Acceptance criteria

- Positive tests use `:type: simulation elaboration parsing`, tag only the directly tested LRM feature, and emit at least one effective `:assert:`.
- Negative tests use one invalid rule per file with a precise `:should_fail_because:`.
- Tests follow the README's minimal, one-feature-per-test convention.
- Expected values follow the LRM exactly and avoid implementation-specific assumptions.
- The §5.7.1 report cell can distinguish syntax acceptance from value-correct behavior.

Start with the repository README's test conventions and the existing 5.7.1 tests, especially tests/chapter-5/5.7.1--integers-token.sv and the direct negative cases described in the issue. Review tools/runner's default test type and the cited standards rules, then add minimal, directly tagged tests. Done means positive cases check values in simulation and negative cases each fail for one specified rule, meeting the acceptance criteria.

Written by the indexing model from the issue text.