feat: attach mode for tinfoil.publish, upload assets to an existing release

[joshrotenberg]

Problem

mix tinfoil.publish always creates the GitHub Release. If one already exists
for the tag it errors, and the only escape hatch is --replace, which deletes
the existing release and recreates it from commit-derived notes.

That breaks any project where something else already owns release creation.
release-please is the common case: merging the release PR tags v0.3.4, creates
the GitHub Release, and writes the curated changelog section as the body. The
tinfoil workflow then fires on the same v* tag and finds the release already
there. --replace works, but discards the changelog body that release-please
just wrote and replaces it with auto-generated notes, which is a downgrade.

hexpm-mcp is hitting this now (joshrotenberg/hexpm-mcp#68) and is shipping with
--replace as a stopgap. changesets and any hand-rolled "tag then release"
setup have the same shape.

Proposal

--attach: look up the release for the tag, upload the archives and
checksums-sha256.txt to it, and leave the release body, prerelease flag, and
draft state untouched. Error if no release exists for the tag, since the whole
point is that something else created it.

That gives three coherent modes:

mode	release exists	behavior
default	no	create, then upload
default	yes	error, tell the user about --attach and --replace
--attach	yes	upload only, do not touch the release
--attach	no	error
--replace	yes	delete, recreate, upload

The upload path already exists and already handles the asset list and the
combined checksums file, so this is mostly a matter of skipping the create step
and resolving the release id by tag, which find_release in Tinfoil.Publish
already does for --replace.

Generated workflow

Attach mode is only useful if the workflow can run after the other tool has
created the release. Worth pairing this with a trigger option so the generated
release.yml can use on: release: [published] (or workflow_call, so a
release-please workflow can invoke it directly) instead of on: push: tags.

Without that, the tag-push trigger races the release creation and attach fails
intermittently, which is worse than the current honest error.