docs: note package/publish gaps blocking the 10MB-fix release

Code fix (35f1f972) is done, tested, and pushed. Package build + Forgejo
package-registry publish is blocked on missing packaging conventions
here (no existing publish script/credentials/target-scope decision) --
see NOTES-package-publish-todo.md for what's needed to finish this.

NOTES-package-publish-todo.md

@@ -0,0 +1,60 @@
+# Status: 10MB IPFS `cat` fix — code done and pushed; package build/publish still needs your input
+
+## Done (verified, no further action needed)
+
+- Root-caused and fixed the bug: `crates/radicle-cli/src/ipfs.rs`'s `cat()` used ureq's
+  `Body::read_to_vec()`, which silently caps reads at 10MB (a default meant for typical JSON
+  API responses, not LFS content). Any LFS object over 10MB failed with "the response body is
+  larger than request limit: 10485760" — this is exactly what broke `blog-deploy.service` on
+  the VPS today, on `assets/posts/hashcash/thumbnail.xcf` (29MB).
+- Fix: raised the limit to 1GiB via ureq's `.with_config().limit(...)`. Commit `35f1f972`,
+  branch `rad-lfs-ipfs`.
+- Verification performed:
+  1. Added a `#[cfg(test)]` regression test (`ipfs::tests::cat_round_trips_content_larger_than_ureqs_default_10mb_limit`,
+     `#[ignore]`d since it needs a live Kubo daemon) — a 15MB add+cat round-trip.
+  2. Confirmed it **fails** with the exact production error when the fix is reverted, and
+     **passes** with the fix in place.
+  3. Ran the full `radicle-cli` test suite (123 tests) — one pre-existing, unrelated failure
+     (`rad_help`, a stale `--help`-output snapshot missing the `lfs` subcommand — confirmed to
+     fail identically on the unmodified base commit, nothing to do with this change).
+  4. `cargo clippy` clean (one pre-existing warning in an unrelated file/crate).
+  5. **Live reproduction against the real file**: moved aside the cached LFS blob for
+     `thumbnail.xcf` in `~/Blog/Blog`, ran `rad lfs fetch` with the *old* installed binary —
+     reproduced the identical production error byte-for-byte. Ran it again with the *newly
+     built* binary — the 10MB error is completely gone; it now correctly proceeds to the next
+     step (prompting for a passphrase to decrypt the private-repo content, which is expected
+     behavior and unrelated to this bug — I did not attempt to supply a passphrase). Restored
+     the blog repo's `.git/lfs/objects` cache back to its original state afterward; no changes
+     left in `~/Blog/Blog`.
+- Pushed to `origin` (the Forgejo remote, `ssh://git.hswro.org:9022/mab122/radicle-heartwood-lfs.git`),
+  branch `rad-lfs-ipfs`, commit `35f1f972..4ae9756a`.
+
+## Not done — needs your call
+
+I did **not** build or publish a package. Stopping here rather than guessing, because:
+
+1. **No existing Forgejo-package publishing path in this repo.** There's a `build/Dockerfile`
+   that cross-compiles reproducible `.tar.xz` releases (4 targets: linux/macOS ×
+   x86_64/aarch64) via `cargo-zigbuild`, but nothing that uploads anywhere — no CI workflow,
+   no `curl`-to-package-registry script, nothing referencing Forgejo's package API. I don't
+   know what package type you want registered (generic package? a distro-specific one?), what
+   name/version scheme you use there, or the auth (token?) needed to publish to
+   `git.hswro.org`'s package registry. I deliberately did not go hunting through credential
+   stores (`~/.netrc`, etc.) to find one myself — that's exactly the kind of thing I should ask
+   about rather than dig for.
+2. **The existing Dockerfile's package doesn't include `rad-lfs-transfer`** — only `rad`,
+   `git-remote-rad`, and `radicle-node` get copied into the release tarball. `rad-lfs-transfer`
+   is a separate crate/binary (`radicle-lfs-transfer/`) and is required for this fork's whole
+   LFS-over-IPFS feature to work on a fresh install — worth fixing in the Dockerfile too, but
+   I didn't want to change the packaging script's scope without confirming that's wanted.
+3. **Platform scope is unclear.** The existing Dockerfile builds all 4 targets (needed for a
+   real public release); the VPS only needs `x86_64-unknown-linux-musl`. Building all 4 takes
+   meaningfully longer and needs the macOS SDK blob (`build/macos-sdk-11.3.tar.xz`) and Zig
+   cross-toolchain set up — I can do it, but wanted to confirm whether you want the full
+   release matrix or just what's needed to update the VPS.
+
+If you want me to keep going on this (rather than picking it up in the session that already
+knows this fork's packaging conventions), I'd need: the Forgejo package type/target and an
+auth token (however you'd like to provide it — e.g. via an env var you set, not me searching
+for it), confirmation on whether to add `rad-lfs-transfer` to the Dockerfile's package list,
+and whether to build the full 4-target matrix or just linux/x86_64.