workflow outage: publish-miner.yml has failed on consecutive runs

[JSONbored]

publish-miner.yml has failed on 3 consecutive runs.

That is no longer a flake being retried -- a deterministic failure fails identically every time, so this
has been broken for that entire stretch and every run since the first one was already telling us so.

Check the most recent run's logs, fix the cause, and close this issue. It is re-filed automatically only
if the failure streak reaches 3 again after a success.

Filed automatically by scripts/escalate-workflow-outage.ts (#10146).

[linear-code]

JSO-7104

[JSONbored]

Resolved — and the cause was not a defect in publish-miner.yml.

What actually happened

All six failing runs were manual workflow_dispatch runs against main, not release-automation dispatches:

run	created	event	actor	ref
30623011646	10:16:58Z	workflow_dispatch	JSONbored	main
30623444510	10:24:29Z	workflow_dispatch	JSONbored	main
30623828470	10:31:14Z	workflow_dispatch	JSONbored	main
30624389604	10:41:02Z	workflow_dispatch	JSONbored	main
30624659907	10:45:43Z	workflow_dispatch	JSONbored	main
30624985336	10:51:26Z	workflow_dispatch	JSONbored	main

Every one failed in the same place — the validate job's tarball smoke-test, which installs the packed tarball into a bare temp dir and therefore resolves dependencies from the real npm registry:

npm error code ETARGET
npm error notarget No matching version found for @loopover/contract@^3.19.0.

@loopover/contract@3.19.0 was not published until run 30625434201 (created 10:59:19Z). The next publish-miner.yml run after that, 30626304881 at 11:13:59Z, succeeded with no code change in between.

Why this is not a workflow bug

The reconciliation job in mcp-release-please.yml already orders this correctly: needs_publish packages/loopover-contract dispatches and waits for publish-contract.yml before either dependent goes, plus a 30s propagation sleep and dispatch_and_wait_with_retry. That machinery was bypassed here because the runs were dispatched by hand against main, ahead of the dependency being live.

So the streak was real and deterministic — the escalation was correct to fire on the signal it has — but the remedy is publish ordering during a manual release, not a change to publish-miner.yml.

Latent finding, filed separately rather than fixed here

scripts/escalate-workflow-outage.ts counts leading non-successes in a workflow's run history without distinguishing a manual dispatch from an automation one. A maintainer retrying a publish by hand three times before its dependency lands therefore reads identically to a standing outage. Worth narrowing to automation-dispatched runs, since those are the ones nobody is watching.

Closing: the streak was broken by a genuine success at 11:13:59Z, and per this issue's own terms it re-files automatically if it reaches 3 again.