docs: fix bug metadata for TRON 0.8.30 security backports + fix: reject Ethereum units in AST imports

[yanghang8612]

Summary

This PR contains two commits addressing audit findings for the 0.8.30 release:

Commit 1: docs: fix bug metadata for TRON 0.8.30 security backports

Follow-up fix for two documentation issues found in the 0.8.29 → 0.8.30 audit (PR #142 security backports):

1. Bug version matrix inconsistency (docs/bugs.json, docs/bugs_by_version.json)

   • SOL-2025-1 (LostStorageArrayWriteOnSlotOverflow), SOL-2026-1 (TransientStorageClearingHelperCollision), SOL-2026-2 (UnsoundSpillInMutualRecursion) and SOL-2026-3 (InheritanceOrderReversalOnStorageEndWarning) were backported to TRON 0.8.30 via Backport SOL-2025-1 through SOL-2026-3 fixes to release_0.8.30 #142, but their fixed fields still pointed at the upstream Ethereum releases (0.8.32/0.8.34/0.8.36). As a result, bugs_by_version.json claimed 0.8.30 is still affected by all four bugs.
   • The fixed fields now say 0.8.30 on this release line, and docs/bugs_by_version.json was regenerated with scripts/update_bugs_by_version.py: 0.8.29 correctly lists all four bugs as affecting it, while 0.8.30 lists none.
   • The regenerated file also drops the 0.8.31–0.8.36 entries, which is the deterministic output of the generator for this branch (its Changelog.md ends at 0.8.30); those entries were upstream merge leftovers inconsistent with this branch.

2. TRON terminology regression (docs/bugs.json)

   • The Backport SOL-2025-1 through SOL-2026-3 fixes to release_0.8.30 #142 cherry-picks overwrote TRON-adapted wording (Trx) with upstream wording (Ether) in three legacy bug entries: SOL-2017-5 (ZeroFunctionSelector), SOL-2016-7 (LibrariesNotCallableFromPayableFunctions), SOL-2016-6 (SendFailsForZeroEther).
   • Restored the exact 0.8.29-baseline wording.

Commit 2: fix: reject Ethereum units in AST imports

Fixes a unit-policy inconsistency between compilation entry points (audit ref CR-009):

• Problem: the source parser explicitly rejects wei/gwei/ether (Parser.cpp, "Ether unit denomination is not supported by the compiler"), but the same literal node imported via Standard JSON language=SolidityAST was silently accepted and constant-evaluated with Ethereum multipliers (e.g. 1 ether → PUSH8 0x0de0b6b3a7640000, 10^18 instead of TRX's 10^6).
• Fix (three layers):
  1. ASTJsonImporter::subdenomination() now rejects wei/gwei/ether with astAssert; the new catch (InvalidAstError) in StandardCompiler::compileSolidity() turns it into a clean JSONError ("Failed to import AST: ...") instead of a fatal exception.
  2. SyntaxChecker::visit(Literal) rejects Ether denominations at the unified post-import analysis stage, with the same error id and message as the parser.
  3. RationalNumberType::isValidLiteral() treats Wei/Gwei/Ether as invalid, so even programmatically constructed Literals cannot be constant-evaluated with Ethereum multipliers.
• Tests: StandardCompiler/solidity_ast_rejects_ethereum_subdenominations (cross-entry end-to-end: compile 1 trx from source, patch the exported AST to wei/gwei/ether, feed back via SolidityAST, expect JSONError and no contracts output) and SolidityTypes/ethereum_subdenominations_are_invalid.
• Known residual (accepted): libsolidity/experimental/analysis/TypeInference.cpp still contains Ethereum multiplier handling for these denominations. It is unreachable — the experimental pipeline shares the same parser, and the AST import path is now guarded — and is intentionally left unchanged in this PR.

Verification

• Docs commit: python3 -m json.tool passes for both files; scripts/update_bugs_by_version.py output is byte-identical (reproducible).
• Fix commit: both new tests pass; original PoC (ether/gwei via SolidityAST) now rejected with JSONError and no bytecode; source entry for trx/sun/time denominations unchanged (10^6 / 1 / time multipliers verified in bytecode); source entry still rejects 1 gwei at parse time.
• Regression: SolidityTypes, SyntaxChecker, ASTJSON suites pass; syntaxTests failures (25) are byte-identical to the parent commit (all pre-existing fork debt); the 3 StandardCompiler/basic_compilation failures are the known pre-existing hardcoded-bytecode expectations not adapted to TRON token-value guards.

Notes

• Draft: the version-matrix semantics (fixed: 0.8.30 on the TRON release line vs upstream fixed versions) should be confirmed by reviewers before merge.

[github-actions]

Thank you for your contribution to the Solidity compiler! A team member will follow up shortly.

If you haven't read our contributing guidelines and our review checklist before, please do it now, this makes the reviewing process and accepting your contribution smoother.

If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the #solidity-dev channel on Matrix.