Add unity-sync, a mirroring CLI for the Unity Asset Store

[curbol]

What

A Go CLI that mirrors the assets you own on the Unity Asset Store into a local library,
downloading only what changed since the last run. select picks what to mirror through a
local page, status says what a sync would change, sync fetches the delta, list prints
the lockfile, update replaces the binary from a release.

Three files hold the state, deliberately apart: user config and the pasted session live
outside any project, the unity-sync.toml allowlist and its unity-sync.lock.json live in
the project that consumes the assets and get committed, and the packages themselves live in
an expendable cache at <library>/<publisher>/<asset>/<asset>.unitypackage.

51 files, all new; the repo was empty. Commits are narrative and read in dependency order,
with one deliberate exception: the fixture scrubber lands first, because everything after it
consumes fixtures and committing the raw captures even briefly would put entitlement ids in
git history where an edit cannot remove them.

Why

The Asset Store gives you no way to pull the packages you have bought outside the Editor,
and an account of a few hundred assets is tens of gigabytes with individual packages
reaching 23 GB. Re-downloading the world to find the one thing that changed is not viable,
so the whole design is about answering "what changed" cheaply and never trusting a file it
did not verify.

The store makes that harder than it sounds, and most of the code is a response to something
measured rather than assumed:

• The LS cookie is the entire credential. Not the NextAuth session token, which neither
  endpoint consults. LS is a session cookie no browser writes to disk, which is why the
  tool asks for a paste instead of reading your cookie database. See DECISIONS.md item 1 in
  the run notes: whether the zero-paste UX is worth chasing is a real open question.
• A missing LS returns an HTTP 500 that reads like a server fault, so its absence is
  asserted locally before any request goes out.
• An expired session 302s to Unity's OAuth page, which is why no store client follows a
  redirect. selfupdate is the one deliberate exception, since GitHub's asset API 302s to
  a signed CDN URL by design.
• Asking for gzip makes the download endpoint gzip the already-gzipped package, so
  downloads ask for identity.
• The store carries two version identities that routinely disagree: the id it advertises
  and the id it actually serves. Both are recorded, and the advertised one is the diff key,
  because pairing a refreshed id with an unresolved entry would mark that entry current
  forever.

Testing

The suite is fully offline: go test -race ./... across 14 packages, against httptest
servers and scrubbed fixtures. go vet ./... and gofmt -l . are clean, and CI runs the
same three.

It was also run live against a real 176-asset account: select through save, first sync,
the two-version-id warning, an unchanged no-op run, a stale diff key forcing a re-download,
truncation caught by the cheap check, a mid-file flip caught only by --verify, adoption
of an orphaned file with and without a lockfile entry, the version gate refusing to adopt a
mismatched one, a forced rename relocating the directory, a delisted asset reported without
failing the run, four concurrent downloads, and a corrupted LS reported as an expired
session with the lockfile untouched. All passed. The one finding it produced, a delisted
asset counted but never named, is fixed, and the live checks were re-run against the
finished binary.

The diff then went through five review rounds, which raised 38 findings; 34 were fixed and
4 judged not worth acting on. The ones worth knowing while reading it:

• Adoption could wedge an asset permanently. When a cached file failed verification and a
  good copy of the same package existed elsewhere, the good copy had nowhere to land: the
  damaged file still held the derived path, and Relocate refuses an occupied destination.
  Nothing resolved, the entry carried forward unchanged, and every later run failed the
  same way.
• The store client raced on the credential itself, because a mid-flight CSRF re-bootstrap
  writes cookie and csrf while the download pool reads them.
• Under --verify, every out-of-date asset was fully re-hashed immediately before being
  replaced by its own re-download.
• The lockfile and the manifest, the two files this design most wants committed, were
  landing as 0600.
• Every diagnostic in install.sh was unreachable: the script runs under set -e with
  pipefail, and each guard sits after an assignment from a pipeline, so the first failure
  a new user hits printed nothing at all.

Each has a test that fails against the previous code, except the --verify one, which is a
performance property with no behavioural observable and is verified by reading.

Worth knowing: the review stopped at its round cap, not because a round came back clean.
Findings per round were 10, 7, 7, 9, 5. What changed across rounds is where they were. The
Go code stopped yielding anything that would hold a merge by round 4, and round 5's only
significant finding was in install.sh, which no earlier round had read closely, so the
shell and workflow files have had one careful reading rather than five.

Notes

• Private repo, so install.sh and update both authenticate with gh or GITHUB_TOKEN.
• No account data reaches the repo: sessions and raw captures are git-excluded and a guard
  test fails the build if PII lands in testdata/.
• Browsing the mirrored library is deliberately out of scope; that is
  quarry, and the three-level cache layout exists so
  its vendor and pack filters work against this tree.