publish: auto-create toolkit on first upload (match PyPI/npm convention)

[tonymenzo]

Proposal

stk publish should create a new toolkit on the registry as a side
effect of the first upload, the way twine upload (PyPI),
npm publish, cargo publish (crates.io), gem push (RubyGems),
and mix hex.publish (Hex) all do. Today the CLI requires the
toolkit to be pre-registered through https://scitoolkit.org before
publish will succeed; an unrecognized name returns 404 from
POST /api/toolkits/{name}/publish
(scitoolkit/cli.py:1766-1787, falling through to the generic
error branch at cli.py:1852-1861).

The web-UI registration flow can stay as an alternative path for
authors who want to set metadata before they have a tarball ready.
The CLI flow just shouldn't require it.

Why this is the right default

The dominant package-registry convention is "account required,
package not." First upload claims the name. This is what authors
arrive with as a mental model from PyPI, npm, crates.io, etc. —
asking them to detour through a web UI is non-obvious friction,
especially since the existing 404 error message
(Toolkit '<name>' not found) doesn't tell them what to do
about it.

The pre-registration model has one defensible benefit — letting
the registry attach metadata (description, owner, category) to
the project record before any upload exists — but toolkit.yaml
already carries all of that, so the registry can populate the
project record from the tarball's manifest on first upload. No
information is lost.

Suggested CLI shape

When POST /api/toolkits/{name}/publish returns 404 ("toolkit not
registered"), the CLI should:

1. Confirm the name is available (registry endpoint can return
   "available" vs "taken by another account" — the latter is
   a 403/409, not a 404).
2. Prompt: "Toolkit '' is not yet registered. Create it
   under your account and publish v? [Y/n]" — bypassed
   by --yes / -y and skipped under --no-input (with sensible
   default per _resolve_prompt_mode).
3. Hit a registration endpoint (new, e.g.
   POST /api/toolkits with the manifest payload) before
   re-attempting the upload, or fold registration into the
   publish endpoint server-side ("create-if-not-exists" semantics).

The server-side fold is cleaner — one round trip, atomic. The
client-side two-step is easier to ship without backend changes.

Tradeoffs to weigh

• Typo-squatting / namespace pollution. PyPI has rate limits
  and account-age checks; SciToolkit could do the same. Not a
  reason to keep the friction, just a reason to add appropriate
  controls server-side.
• Discoverability. Pre-registration gives the registry a
  project record it can index even with no published versions;
  the auto-create flow only indexes after the first upload.
  Probably fine — empty toolkits aren't useful to discover anyway.
• Backwards compatibility. Web-UI pre-registration keeps
  working unchanged. This issue only proposes adding a CLI
  path, not removing the existing one.

Real-world hit

I ran stk publish on a freshly-ingested toolkit and got
Toolkit 'heptapod' not found / Status code: 404. Coming from
PyPI/npm I expected the upload to register the name; instead
I had to trace publish's source to figure out the web-UI step
existed. #4 covers documenting the current behavior in
ingest's Next-steps banner; this issue covers fixing it instead.

Relevant files

• scitoolkit/cli.py:1766-1787 — stk publish upload call
• scitoolkit/cli.py:1852-1861 — generic error branch where
  the 404 currently surfaces
• scitoolkit/cli.py:466-485 — stk init's registry probe,
  the existing pattern for "toolkit-doesn't-exist-yet" handling

Related

• ingest: Next-steps should mention the web-UI registration before publish #4 — documents the current "must register on web first"
  behavior in ingest's Next-steps. This issue makes that
  documentation unnecessary by removing the requirement.
• ingest: warn when files are dropped due to unresolvable module path #1, ingest: scaffold mcp/ alongside toolkit.yaml so 'validate' passes #2, mcp/server_stdio.py template: pre-orchestrator artifact, standalone use is broken in two ways #3 — also surfaced during heptapod onboarding.