Now that auth works with the long-lived API key, two latent bugs in
the Brev E2E harness surface immediately:

1. 'Cannot find module ../dist/nemoclaw' when the test-harness
   invokes bin/nemoclaw.js for pre-flight sandbox-name validation.
   The workflow runs 'npm install --ignore-scripts' (to avoid the
   git-hook installer) which skips the 'prepare' script that would
   otherwise build dist/. Add an explicit 'npm run build:cli' step
   after install.

2. 'listBrevInstances(...).some is not a function' inside the
   cleanupLeftoverInstance beforeAll hook. The v0.6.324 'brev ls
   --json' output is no longer a bare array (v0.6.322 was) \u2014
   it now returns either null or an object wrapper. Make the
   parser defensive about array/{workspaces}/empty shapes so
   CLI version drift never breaks the harness again.

Both were latent because the workflow has been dispatch-only with
an expired refresh-token for weeks; no run has made it past auth to
exercise these paths.

Previous defensive fix (98e680e) still produced '.some is not a
function' on the fork validation run, which means brev ls --json
is returning a shape my guards didn't cover. Two changes:

1. vitest.config.ts: the e2e-branch-validation project was still
   gated on BREV_API_TOKEN (old secret name). Gate on either the
   new BREV_API_KEY or legacy BREV_API_TOKEN so the project is
   explicitly enabled under the new auth.

2. test/e2e/brev-e2e.test.ts: make listBrevInstances() fully
   diagnostic. Separate the brev-call and JSON.parse try blocks,
   log the raw output + parsed shape when we can't find an array,
   and check a wider set of wrapper keys (workspaces, instances,
   data, result, items). Guarantees an array return + tells us
   what the real v0.6.324 shape is for a clean future fix.

The last 3 fork validation runs silently tested main instead of the
branch the dispatch targeted. The checkout step used:

  ref: ${{ env.RESOLVED_BRANCH || inputs.branch || 'main' }}

But 'branch' is only defined on workflow_call, not workflow_dispatch.
For workflow_dispatch without a PR number, both fallbacks were empty
and it used the literal 'main', ignoring --ref. All branch-level test
fixes were invisible to the runs.

Two changes:
  - Add an explicit 'branch' input to workflow_dispatch so the target
    branch can be named in the UI / CLI dispatch.
  - Change the final fallback from 'main' to github.ref_name. That's
    the ref the dispatch was triggered against (what 'gh workflow run
    --ref X' passes), which is what every caller actually meant.

Missed the 3rd aggregate job. nightly-e2e.yaml has three fan-in jobs
that each depend on every real E2E job via 'needs:':
  - notify-on-failure  (updated in c9d48ac)
  - report-to-pr       (updated in c9d48ac)
  - scorecard          (missed)

The repo-level test/validate-e2e-coverage.test.ts lints this invariant
and was failing on all hosted-runner jobs (wsl-e2e, macos-e2e, regular
cli project) with:

  Nightly E2E aggregate jobs missing real E2E jobs in needs:
  scorecard -> brev-e2e.

Add brev-e2e to scorecard's needs list to restore the invariant.

The whole point of Brev E2E coverage is to validate the image that
customers actually get. Until now the harness provisioned a bare
Ubuntu VM and ran scripts/brev-launchable-ci-cpu.sh \u2014 a parallel
reconstruction of what the image is supposed to look like. That
bypasses the image build pipeline entirely, which means:

  - Regressions in brevdev/nemoclaw-image (containerd pre-import,
    systemd services, submodule SHA) are invisible to us.
  - Drift between the published launchable and what customers get
    is undetectable.
  - The 2-min fast-boot property the image exists to deliver is
    untested.

Switch to 'brev create --launchable env-3Azt0aYgVNFEuz7opyx3gscmowS'
(the public NemoClaw launchable surfaced in docs/deployment/brev-
web-ui.md) by default. The startup-script path is retained as an
opt-out fallback (USE_PUBLISHED_LAUNCHABLE=0) for validating the
setup script itself without touching the image.

Changes:
  - test/e2e/brev-e2e.test.ts: new createBrevInstance() branch that
    uses --launchable; new readiness probe (nemoclaw + openshell
    on PATH + ~/NemoClaw present) instead of the sentinel file the
    startup-script wrote but the published image does not.
  - workflows/e2e-branch-validation.yaml: new use_published_launchable
    + launchable_id inputs (workflow_dispatch + workflow_call),
    defaulting to the published image.
  - workflows/nightly-e2e.yaml: brev-e2e matrix now explicitly
    requests the published launchable.

Expected impact on run time: provisioning drops from ~5 min
(bare VM + full bootstrap) to ~2 min (pre-baked image boot).

…unchable

Run NVIDIA#6 failed at refreshAndWaitForSsh with 'SSH not ready after 40
attempts' but produced NO diagnostic output between env-dump and
failure. Two fixes:

1. vitest.config.ts: override silent:isCi for the e2e-branch-validation
   project. The whole suite is one describe block so there's no test
   chatter to suppress, and diagnostic output from createBrevInstance
   / waitForSsh / waitForLaunchableReady is essential for Brev timing
   debugging. Local runs already show this; CI should too.

2. waitForSsh: default attempts by mode. Bare-VM startup-script path
   keeps 40 attempts (~5 min). Published launchable gets 96 attempts
   (~12 min) because the pre-baked image boot is fast (~2 min) but
   Brev platform SSH-proxy registration for launchable-provisioned
   instances appears to lag several more minutes before brev refresh
   picks them up. Empirical from run NVIDIA#6: instance created but SSH
   never came up in the 5-min window.

Run NVIDIA#7 failed at the 'brev ls' sanity check in the Install Brev CLI
step with:

  API key saved for org ***
  rpc error: code = Internal desc = context deadline exceeded

Confirmed from local testing: the Brev platform's workspaces/list
endpoint is currently returning 'context deadline exceeded' across
MULTIPLE orgs (not just Nemoclaw CI/CD), even with working
credentials. Other endpoints (brev org ls, brev login) work fine.
This is a transient platform issue, not a credential or code issue.

Add a 5-attempt retry loop with 15s backoff around the brev ls
sanity check. On final failure, emit a ::warning:: and proceed \u2014
the test harness's own waitForSsh / refreshAndWaitForSsh calls
retry brev refresh on their own, so downstream steps will still
validate auth works. We only want to fail here if auth is
genuinely broken (e.g., wrong key), not because Brev's backend
is having a bad hour.