chore: point GitHub org references at movement-network

[ganymedio]

Important

Hold — merge and promote at the time of switching the repos to the movement-network org. The move init template, migration-package deps, and CI uses:/ghcr.io references resolve against the new org name, so this lands with the rename.

Summary

The movementlabsxyz GitHub org is being renamed to movement-network. This swaps the org name across all 33 references (19 files):

• crates/aptos/src/move_tool/mod.rs — APTOS_GIT_PATH, the constant move init writes into generated Move.toml files, so newly scaffolded packages depend on the new org.
• aptos-move/aptos-release-builder/src/components/framework.rs — MVT_APTOS_GIT_PATH, plus data/release.yaml source/discussion URLs.
• movement-migration/*/Move.toml (6 packages) — AptosFramework git deps.
• CI/tooling — workflow uses: .../aptos-core/.github/actions/... refs, ghcr.io image namespaces (build-versions.yaml, publish-builder-images.yaml, Justfile), the PR-audit reviewer repo ref, and scripts/cli/build_cli_release.sh release-URL check.
• Docs/metadata — homebrew README, aptos-debugger README, a source-citation comment, and proposal metadata URLs.

Verification

• String/config-only diff (constants, comments, YAML/TOML/JSON/docs); no logic touched. git grep movementlabsxyz returns zero hits after the change.
• cargo check not run — the three touched .rs lines are string literals inside existing constants/comments; say the word if you want a workspace check run anyway.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}

[Primata]

Checked the mechanics of this rename rather than the intent — with movementlabsxyz becoming movement-network, the references land correctly once the rename happens, and GitHub's redirects mean the ordering is forgiving in the meantime.

Coverage is complete, for what it's worth: all 6 Move.toml files under movement-migration/ carry the AptosFramework git dependency and all 6 are updated, and of the 6 workflows only build-versions.yaml (9), claude-audit-pr.yml (2) and publish-builder-images.yaml (1) reference the org — all three are covered, and the 12 changed workflow lines account for every one. The framework packages under aptos-move/framework/ use path dependencies rather than git, so nothing hidden there.

One thing I'd like a second opinion on before merge — a question about the governance proposal metadata, inline. Everything else here looks mechanical and fine.

Two small notes that don't need action, just flagging:

• scripts/cli/build_cli_release.sh — the "already released" guard is if curl -f <releases URL>. During the window where the new org exists but release assets haven't been re-pointed, -f returns non-zero on a 404 and the check silently reads as "not yet released", so the script would proceed instead of exiting 3. Self-correcting once releases live at the new org, but worth knowing if a release is cut mid-migration.
• movement-migration/*/Move.toml pin rev = "movement" and rev = "l1-migration"; those branch names need to survive the rename, which they should, but they're the kind of thing that's easy to miss if any branch is recreated rather than moved.

[Primata]

Question rather than a blocker — is this file safe to rewrite after the fact?

The org migration makes the other 32 lines in this PR correct-by-construction, and GitHub's rename redirects mean they'd keep resolving even before consumers catch up. This file is the one I'm not sure that reasoning covers.

Governance proposal metadata isn't only documentation. When a proposal is created, the metadata location and a hash of this JSON are recorded on chain, and the standard way to verify a proposal is to fetch the file and check that it still hashes to what the proposal committed to. Editing any byte — including a URL inside it — changes that hash.

This particular proposal looks executed rather than pending: feature 67 (CONCURRENT_FUNGIBLE_BALANCE) reads as disabled in the 0x1::features::Features bitmap on mainnet today, which is what this proposal was for, and the directory is dated 2026-04-08. So the concern isn't breaking a live vote, it's that anyone auditing the historical record afterwards gets a mismatch and has to work out whether it's a rename or something worse.

Three ways this could go, and I don't know which is right for this repo:

1. Leave the file untouched and treat proposals/ as an append-only archive. Old URLs keep redirecting, so nothing is actually broken by leaving it. This is what I'd guess, but it depends on whether anything downstream re-verifies these hashes.
2. Rewrite it and accept the hash drift, on the basis that nobody verifies historical proposals against the repo.
3. Rewrite it and record the original hash alongside, so the drift is documented rather than discovered.

Worth checking with Ru or Zekun before this merges — they'll know whether these hashes are verified anywhere in practice, and whether proposals/ is treated as an archive or as ordinary source. Happy to go with whatever they say.

Note that aptos-move/aptos-release-builder/data/release.yaml carries the same two URLs but is a template for future proposals, so updating it looks unambiguously right — the question is only about the already-created metadata under proposals/.