GeezerVison

Extract the None-return scanner fix from #8954, without capsule hooks or interpreter lifecycle changes.

The scanner now uses decoded logical instructions and full-width constant indices. Static example: EXTENDED_ARG 1; LOAD_CONST 0 addresses constant256, not constant0. If constant0 is None and constant256 is True, the old scanner incorrectly accepts the return; reversing those constants causes a false rejection.

The split also corrects two issues found during review of the original mega implementation: common-constant decoding is fallible, and loaded constants are checked by None identity rather than converting arbitrary co_consts objects. This avoids new panic paths and unnecessary conversion allocations.

Validation:

• cargo check -p rustpython-vm --lib --locked, with and without --features threading: passed.
• cargo clippy -p rustpython-vm --lib --locked, with and without --features threading, using -D warnings: passed.
• Fresh release build with threading, without capi/JIT/frozen Lib: passed.
• Existing canonical test.test_code.CodeTest.test_returns_only_none: exactly one test passed, no skips.
• Normal commit hooks: merge-conflict check, rustfmt and cspell passed.

The canonical test covers ordinary returns; it does not distinguish the extended-operand case. That correction is supported by source-level operand analysis, not an added runtime probe. CPython3.15 explicitly leaves EXTENDED_ARG handling out of its equivalent scanner, so this is RustPython full-width operand correctness rather than a CPython boundary-parity claim. No Python tests or assertions were changed. Full workspace/C-API suites and capsule lifecycle execution were not run.

AI assistance is disclosed in the commit trailer; the exact model identifier was unavailable.