Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@crates/compiler-core/src/marshal.rs`:
- Around line 472-474: The tuple deserialization resets the recursion budget and
allows nested code->const tuple->code chains to bypass limits; change
read_marshal_const_tuple (and similar helpers used in lines ~487-516) to accept
the current depth parameter and call read_const_value(rdr, bag, depth - 1, refs)
for each element instead of using MAX_MARSHAL_STACK_DEPTH, and ensure
read_const_value passes depth - 1 when it recurses into deserialize_code_inner
so the depth budget is threaded through and decremented across code-object
helper boundaries (references: read_marshal_const_tuple, read_const_value,
deserialize_code_inner, MAX_MARSHAL_STACK_DEPTH).
- Around line 704-715: The current Type::Code branch in deserialize_value_depth
creates a fresh inner_refs Vec (and only reserves slot 0 when FLAG_REF is set)
which resets the TYPE_REF index space and prevents code-object fields from
resolving refs from the outer stream; change this to reuse the caller's ref memo
or maintain an index-aligned mapping so TYPE_REF indices remain consistent:
instead of creating a new inner_refs Vec in the Type::Code arm, pass the
existing ref memo (or construct a mapping that pre-populates entries to preserve
index alignment) into deserialize_code_inner, ensuring deserialize_code_inner
and bag.make_code operate against the same ref index space as the surrounding
marshal stream (referencing deserialize_value_depth, inner_refs,
deserialize_code_inner, Bag::ConstantBag::Constant, TYPE_REF, FLAG_REF, and
bag.make_code).

In `@crates/vm/src/stdlib/sys.rs`:
- Around line 661-662: The cache tag change makes RustPython emit the same
__pycache__ filenames as CPython, risking cross-interpreter .pyc conflicts;
revert the tag to a RustPython-specific prefix (e.g., change the cache_tag
creation from "cpython-{}{}" to "rustpython-{}{}" using version::MAJOR and
version::MINOR) and/or add defensive validation in the .pyc loader to detect and
refuse incompatible marshalled bytecode (so when reading .pyc files you check
the tag/magic and fail-safe rather than attempting to execute another
interpreter's bytecode).

In `@crates/vm/src/version.rs`:
- Around line 72-73: Update the PYC_MAGIC_NUMBER constant from 3627 to 3658 to
match CPython 3.14: change the value of PYC_MAGIC_NUMBER in version.rs and
update the accompanying comment to reflect CPython 3.14; then run and adjust any
unit tests or logic that assert or compute against PYC_MAGIC_NUMBER (search for
references to PYC_MAGIC_NUMBER, pyc magic, or functions using that constant) so
they expect 3658 and any derived behavior remains correct.

---

Outside diff comments:
In `@crates/compiler-core/src/marshal.rs`:
- Around line 825-845: The dict-key branch duplicates decoding logic and calls
deserialize_value_typed(...) directly, which bypasses the raw-header/code-object
handling in deserialize_value_depth and causes Type::Code keys to be rejected;
change the key decoding in this branch to first determine the key's
type_code/header (using the same raw/FLAG_REF/ref-slot handling as shown) then
invoke the common decoder path used by deserialize_value_depth (so code objects
go through the same raw-header/code-object route), i.e., extract the differing
value (the key_type or ref index) and call the shared decode routine rather than
duplicating deserialize_value_typed logic; update use of refs, key_slot, and k
to follow the same flow as deserialize_value_depth so Type::Code is accepted for
dict keys.