fix(npm): scope the platform packages to sidestep npm spam detection

[adhikjoshi]

403 Package name triggered spam detection - PUT modelslab-cli-win32-x64

Not a token problem. Five platform packages published fine — with signed provenance — seconds earlier. A thin, unscoped package whose name matches a very common platform-suffix pattern is exactly the shape npm's heuristic targets, and win32-x64 is the most heavily squatted of the six suffixes.

The fix

Platform packages become @modelslab/cli-<os>-<arch>. A scope proves ownership and removes them from the unscoped-name heuristic entirely.

This is what everyone else converged on:

CLI	Platform package
esbuild	@esbuild/win32-x64
Biome	@biomejs/cli-win32-x64
Claude Code	@anthropic-ai/claude-code-win32-x64

esbuild's unscoped esbuild-windows-64 has been frozen at 0.15.18 since 2022, when they migrated for the same reason.

The entry package stays unscoped as modelslab-cli, so npm install -g modelslab-cli is unchanged and still discoverable by name.

Platform packages also gain a README — a two-file package with no readable content is part of what reads as spam, and "do not install this directly" is worth saying to anyone who lands on one.

The orphaned packages

The five unscoped packages v0.1.2 published are stranded at that version. Nothing references them (the entry package never published) and npm does not permit unpublishing, so they are left alone. Same thing esbuild lived with.

Verified end to end

Against a real goreleaser build --snapshot:

6 scoped platform packages + entry built
entry optionalDependencies -> all six pinned at exact version
publish.sh finds them under dist/npm/@modelslab/*
npm install (entry + one platform) -> modelslab --version ✓

Needs you

The @modelslab organisation must exist on npm, and NPM_TOKEN needs publish rights to it. It does not exist yet — I checked. Once it does, tag v0.1.3 and the release completes on all channels.

---

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