Adopt pinned public core snapshot and prepare Sized 2.0.0

SHIPMENT.md

@@ -7,8 +7,9 @@ This document defines the process for versioning and distributing the `sized` pr
 Use a named branch from `main` and keep a pull request focused on one outcome.
 The `sizequeen-scan-hardening` branch corrects accounting/error handling and
 adds the scan controls needed by SizeQueen; the scanner has also been
-extracted into private `sized-core` for SizeQueen. Sized retains its own copy
-until adoption preserves public source access.
+extracted into private `sized-core` for SizeQueen. Sized 2.0 includes its exact
+pinned source snapshot as a path dependency. Verify `CORE-SNAPSHOT.json` before
+packaging; no private Git fetch is part of a public build.
 
 1. Run local locked tests and strict Clippy as an unprivileged user. Run
    `./scripts/check-linux.sh linux/arm64` and
@@ -70,7 +71,7 @@ The project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html
 2.  Update `CHANGELOG.md` with the release notes.
 3.  Commit and create a git tag:
     ```bash
-    git tag -a v1.0.0 -m "Release v1.0.0"
+    git tag -a v2.0.0 -m "Release Sized 2.0.0"
     ```
 
 ## 2. Asset generation and verification
@@ -84,7 +85,7 @@ The project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html
 It packages the executable **before** creating the archive, together with the
 man page, Bash/Zsh/Fish completions, licence, README, manual and build metadata.
 Outputs are `dist/sized-v<VERSION>-<RUST-TARGET>-<REVISION>/`, a sibling `.tar.gz`
-and `.tar.gz.sha256`. Existing outputs are never replaced. Use
+and `.tar.gz.sha256`, including complete dependency notices. Existing outputs are never replaced. Use
 `--output-dir /absolute/new/path` for an explicitly named local candidate.
 `CARGO_TARGET_DIR` is respected. The script does not sign, upload, tag or publish.
 
@@ -100,6 +101,35 @@ against the original checkout. Retain matching source and complete dependency
 licences with any public binary distribution. A host build is unsigned; do not
 advertise it as notarized or as a Mac App Store application.
 
+### Matching source and Mac delivery
+
+From a clean committed source checkpoint, run:
+
+```sh
+scripts/package-source.sh /absolute/new/release-directory
+```
+
+This exports tracked source, includes all locked registry dependencies, verifies
+an empty-cache offline build, and retains the exact source archive. Build the
+binaries from that exported `sized-source` directory with
+`CARGO_NET_OFFLINE=true` and `SIZED_SOURCE_REVISION` set to `SOURCE-REVISION.txt`.
+Linux release checks can retain an archive when `SIZED_RELEASE_DIR` names a
+writable output mount. Run on the architecture being released; keep both tmpfs
+boundary mounts and UID 65532. This does not publish files.
+
+For Mac, use `scripts/notarize-macos.sh PACKAGE_DIRECTORY NEW_DMG_PATH` with an
+explicit `SIZED_SIGN_IDENTITY`. It signs the CLI and disk image, submits through
+`SIZED_NOTARY_PROFILE` (default `sizequeen-notary`), staples and validates the
+DMG. The notarization receipt stays with private build evidence. Distribute the
+DMG; a raw command-line executable cannot carry a stapled ticket. Compute final
+checksums only after signing/stapling, then exercise the mounted signed CLI and
+verify the downloaded files. See Apple's
+[custom workflow guidance](https://developer.apple.com/documentation/security/customizing-the-notarization-workflow).
+
+Publish versioned files on the Gitea release and link them from the existing
+Gamertan CMS project. Keep forge privacy settings unchanged. Retain the exact
+matching source and never overwrite a published asset with different bytes.
+
 ## 3. Distribution channels
 
 The existing public Gitea v1.0.0 release contains a macOS arm64 executable,