fix(release): canary lane has no same-semver republish path — a 503 mid-publish forces a wasted canary.N

[rickylabs]

netscript-release documents same-semver republish as the correct recovery from a partial publish:

JSR version immutability binds only to published members. A member that failed or was skipped
can still publish at the exact same semver, and workspace deno publish skips already-registered
versions... recovery is a fix-forward, not a version bump.

The canary lane cannot do this. Both paths are closed:

• release-canary.yml takes only target-version and always runs release:canary, which derives
  the next canary.N from registry metadata plus the tag collision guard. There is no input to
  re-publish an existing canary tag.
• publish.yml does have a tag input, but it runs release:verify-canary-pair and fails closed
  without a green pair — which is exactly the thing a partial canary has not yet produced. Circular.

So a canary that partially publishes can only be abandoned and re-cut at N+1, which is the one
thing the skill says not to do for the stable lane.

Observed

0.0.2-canary.3 (run 30675075801):
@netscript/sdk failed with a transient 503 Service Unavailable from JSR and took 6 dependents
with it, including @netscript/cli. Everything else published:

@netscript/logger      0.0.2-canary.3  published
@netscript/contracts   0.0.2-canary.3  published
@netscript/config      0.0.2-canary.3  published
@netscript/telemetry   0.0.2-canary.3  published
@netscript/aspire      0.0.2-canary.3  published
@netscript/plugin      0.0.2-canary.3  published
@netscript/sdk         FAILED (503)
@netscript/cli         skipped (dependent)

Nothing was wrong with the content. A retry at 0.0.2-canary.3 would have published the seven
missing members and skipped the rest — instead the whole set must be re-cut at canary.4, leaving
~28 orphaned partial versions behind and consuming a canary number for an infrastructure blip.

Suggested fix

Give release-canary.yml the same escape hatch publish.yml has: an optional tag (or
republish-version) input that skips derivation and re-publishes the existing canary tag. The
byte-identity precondition already documented for the stable lane applies unchanged — the tag must
point at the same content.

Alternatively, let verify-canary-pair recognise an in-progress canary so publish.yml --tag v<version>-canary.N can complete a partial canary publish.

Acceptance

• gate: a canary that partially publishes can be completed at the same canary.N
• gate: the retry publishes only the missing members and logs Skipping, already published for the rest
• gate: a retry whose content differs from the tag is refused, per the byte-identity precondition

Found during the 0.0.2 release while recovering a 503 mid-publish.

[rickylabs]

Moved to 0.0.4 — the fix shipped in 0.0.3, the remaining acceptance scope did not.

PR #1035 merged into 0.0.3 and delivers the reported defect's fix. This issue keeps the acceptance boxes that are still genuinely unmet, so it moves to 0.0.4 rather than being closed on partial evidence.

This follows the owner's ruling on #1012 and #1016: where a merged PR resolves the reported behaviour but leaves acceptance criteria unevidenced, the remaining scope moves forward rather than being ticked to make a milestone look clean. The merged PR deliberately carries Refs #1004 rather than a closing keyword for the same reason — see its "Remaining scope" section for exactly what is left.