fix(ci): the registry canary's triage guidance names the plugin-failed-to-load class (#16794)

* fix(ci): the registry canary names the plugin-failed-to-load class, and says a fix on main does not clear it

The canary's triage template offered a closed binary — build failed, or a
probe failed — and the failure it actually reported fit neither: AuthPlugin
never loaded at boot because @better-auth/core@1.7.3 deleted the export
plugin-auth statically imports, and the probe failures were a consequence.
The template therefore routed the reader to the probes, away from the range.

Add the boot-log branch, order it first (a failed probe is usually a
consequence), and name the local reproducer. Also state the property that
misled this round's triage: this job installs PUBLISHED artifacts, so a fix
merged to main does not clear it — only a release does.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8

* fix(ci): name the reproducer as its node script, not a pnpm run

check:pnpm-acquisition reads a bare `pnpm <cmd>` token anywhere in a `run:`
body as an invocation, so naming the reproducer that way put registry-canary
— a job that acquires no pnpm and needs none — into the population of jobs
that run pnpm (census 31, one failing). The underlying script needs no
package manager and is what a reader can paste, so name it directly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8

* fix(ci): state the reproducer as prose, not a command the gate tooling can discover

Naming the reproducer as `node scripts/check-vendor-export-contract.mjs
--resolve` traded one false positive for another: dispatch-gates discovers
gate families from command-shaped text in `run:` bodies, so the prose became
a discovered family inside registry-canary — a job in a workflow that
declares no PR-time event. check:pm-dispatch-gates went red on its
scheduled-only invariant (4 of 1552 cases), correctly.

Any command-shaped text in a workflow `run:` body is read as a real
invocation by at least two gates, so point at the workflow that runs the
check instead of spelling a command inside guidance prose.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015QE8qk46e5CHJxyQEUjbf8

---------

Co-authored-by: claude <noreply@anthropic.com>

Author: claude[bot]

.github/workflows/publish-smoke.yml

@@ -279,7 +279,7 @@ jobs:
           title="Registry canary failed: fresh npx create-objectstack install is broken"
           existing=$(gh issue list --repo "$GITHUB_REPOSITORY" --state open \
             --search "\"$title\" in:title" --json number -q '.[0].number // empty')
-          body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nRead the run log to see WHICH step failed, because the two have different owners:\n\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\nRun log: %s\n' "$run_url")
+          body=$(printf 'The weekly publish-smoke registry canary failed: a fresh `npx create-objectstack@latest` project no longer completes the first-run path against the npm registry — scaffold, npm install, npm run build, then auth + REST CRUD.\n\nThis job installs PUBLISHED artifacts, so a fix already merged to `main` does NOT clear it — only a release does. Check whether the range or template at fault is already fixed on `main` before opening new work.\n\nRead the run log to see WHICH step failed, because these classes have different owners. **Read the boot log before the probes** — a failed probe is usually a consequence, not the defect:\n\n- **a `failed to load` WARN in the boot log** — a dependency-range problem, and the FIRST thing to check whenever an auth or CRUD probe fails. Specimen: `⚠ AuthPlugin failed to load: The requested module @better-auth/core/db does not provide an export named createLocalAccountIssuer`. A static ESM named import of a missing export is a link-time SyntaxError, so the plugin never loads AT ALL and every later symptom follows from that one failure — core service missing, `sys_*` tables never created, sharing rules never seeded, and the probe failure this job finally exits on. Go to the DECLARED dependency range, NOT to the probe, and establish whether the vendor REMOVED or RENAMED the symbol: the two have different fixes. Reproduce it without waiting for a release using the vendor export-contract check in its resolve mode, which the daily Validate Dependencies workflow already runs: it installs every version each declared range admits and checks that export surface against the symbols we import.\n- **npm run build failed** — the published scaffold is broken on its own second command. This is the #4902/#7644/#8677 class; the fix is in create-objectstack or the template it ships.\n- **an auth or CRUD probe failed over a CLEAN boot log** — this is the #3091 class hitting ALREADY-published versions (e.g. a transitive dependency released into a ^ range).\n\n⚠ `✓ Server is ready` and the plugin count print on a DEGRADED boot too (#16630), so neither is evidence that the boot was healthy and neither narrows the branches above.\n\nRun log: %s\n' "$run_url")
           if [ -n "$existing" ]; then
             gh issue comment "$existing" --repo "$GITHUB_REPOSITORY" \
               --body "Still failing as of $run_url"