refactor(iota-framework-snapshot): split the manifest into a leaf crate

[DaughterOfMars]

Description of change

iota-package-management's build script reads the bytecode snapshot manifest — a JSON file — via iota_framework_snapshot::{load_bytecode_snapshot_manifest, manifest_path}. That single build-dependency edge put iota-framework and iota-types underneath iota-package-management, which iota-move-build and 27 other crates wait for.

The crate splits cleanly in two. The manifest half has no workspace dependency beyond ObjectId, so it can become a leaf crate:

• Add iota-framework-snapshot-manifest holding the Snapshot / SnapshotPackage / SnapshotManifest types, manifest_path, load_bytecode_snapshot_manifest and update_bytecode_snapshot_manifest — unchanged, plus manifest.json itself.
• Re-export it from iota-framework-snapshot (pub use iota_framework_snapshot_manifest::*), so iota-genesis-builder, the snapshot binary and the compatibility tests are unaffected.
• Depend on the new crate from iota-package-management instead.
• The bytecode half — load_bytecode_snapshot, get_system_package_publish_order, snapshot_path_for_version and the bytecode_snapshot/ directory — stays put, since it deals in iota_framework::SystemPackage.

manifest.json moves from crates/iota-framework-snapshot/ to crates/iota-framework-snapshot-manifest/, so that manifest_path() stays a plain CARGO_MANIFEST_DIR join rather than reaching across crates. scripts/update_framework_packages.sh and cargo run --bin iota-framework-snapshot are unchanged — they write the file through update_bytecode_snapshot_manifest either way. CODEOWNERS and .github/crates-filters.yml gain matching entries for the new crate.

Two smaller consequences:

• SnapshotPackage::from_system_package_metadata cannot stay an inherent impl once the type lives in another crate, so it becomes the snapshot_package function in iota-framework-snapshot. Its only caller is the snapshot binary.
• check_if_manifest_was_modified in compatibility_tests.rs matched the manifest by path substring. Left alone it would have silently stopped matching, so check_manifest_against_tomls would have quietly turned into a no-op. It now matches the new path — verified by the test going from 0.05s (skipped) to 28s (cloning and checking out each revision).

Build graph effect

Measured with cargo metadata, workspace crates only, excluding cfg(msim) and wasm32-only edges:

	level before	level after	deps before	deps after
iota-package-management	6	2	13	2
iota-move-build	7	5	18	15
iota-move	8	6	21	19
iota-move-lsp	8	6	19	17
iota-simulator	8	6	20	18
iota-source-validation	8	8	32	29
iota-source-validation-service	9	9	36	34

The longest compilation chain is unchanged at 16 — none of these crates sit on it. This shortens the tail that the Move build path waits for.

Links to any relevant issues

Related to #12234.

How the change has been tested

• Basic tests (linting, compilation, formatting, unit/integration tests)

• Patch-specific tests (correctness, functionality coverage)

• I have added tests that prove my fix is effective or that my feature works

• I have checked that new and existing unit tests pass locally with my changes

• cargo check --workspace --all-targets: zero errors, zero warnings

• cargo nextest run -p iota-framework-snapshot -p iota-package-management: 8 passed, 0 failed — including check_manifest_against_tomls, which validates every historical revision in the manifest against its Move.toml, and the iota-package-management version-table tests, which prove the build script still reads the manifest correctly

• cargo machete, scripts/cargo_sort/run_consolidate.sh, cargo clippy --all-targets and cargo +nightly fmt all clean

🤖 Generated with Claude Code