rainix-autopublish: version intent from next-v git tags; drop all foundry.toml release metadata

[thedavidmeister]

Ruled design (human, 2026-08-19): version intent lives in git tags; foundry.toml carries no release metadata

Supersedes the manifest-floor half of #333 (the registry derivation and no-push-back stay). Ecosystem grounding: every major Solidity project signifies releases with git tags; soldeer consumption in this org is exact-pinned (versioned import paths, checksummed locks), so version numbers carry no range-resolution power — a wrong tag can only mislabel a reviewed release, never change what ships or what consumers install. Therefore no creation-time gate is needed on intent tags; immutability after creation is the property that matters.

Behavior

1. Publish trigger unchanged: push to main; content gate vs the newest published zip. The gate's content normalization widens from blanking the version line to excluding the ENTIRE [external.package] (and legacy [package]) release-metadata section from the hash — so consumers deleting that section is content-neutral and does not mint a spurious release.
2. Version derivation: publish_version = max(patch_bump(newest_published), newest intent tag reachable from the pushed main head). Intent tags match next-v<major.minor.patch> (e.g. next-v0.2.0), scanned via tags merged into the checkout's HEAD. Consumed/stale intent tags are inert under the max. A matching tag that does not parse as major.minor.patch is a loud gate error (fail-safe, consistent with the registry-failure semantics from rainix-autopublish: derive the publish version from the registry; never push back to the consumer branch #333's review fixes).
3. First publish (registry 404 fail envelope or empty revision list, per the pinned API shapes): requires an intent tag — the explicit seed; no tag is a loud error naming the fix.
4. foundry.toml is not read and not rewritten: read_local_version, the local-floor parameter of publish_version, and the soldeer-set-version subcommand are deleted. The published zip carries whatever foundry.toml the repo has (nothing reads release metadata from it).
5. Output unchanged: on publish, sol-v<version> tag on the triggering commit + GitHub release, pushed as tag refs only.

Companion steps (not workflow code)

• Org/repo rulesets: sol-v* and next-v* update- and delete-restricted (create-once immutable), signatures required for attribution. Admin settings action, listed here for the record.
• Consumer sweep after this merges: delete [external.package] and its stale comment from every soldeer-publishing consumer repo (content-neutral under the widened normalization).

Evidence trail

• rainix-autopublish: derive the publish version from the registry; never push back to the consumer branch #333 / rainix-autopublish: derive the soldeer publish version from the registry; never push back to the consumer branch #334: registry-derived versioning, no push-back — merged 2026-08-19.
• The manifest floor's remaining costs it retires: a release-metadata section in every consumer foundry.toml with a comment that went stale the day it merged, plus per-repo first-publish seeding conventions.