Quest CLI 0.7.1

Version frozen 2026-09-15. Breaks lockstep with @opum-ai/lore, once and
deliberately, as 0.6.2 did: lore stays at 0.7.0 and nothing in lore
changes. This is a hotfix for a defect every fleet workspace that paused a
task before 0.7.0 is exposed to, ruled ahead of everything else the same day
it was reported, and holding it for the next paired release would have left
those records unreachable for no reason a consumer benefits from. The one
entry below is additive on the read side (doctor gains an issue code) and
restores a transition on the write side (task start from the retired
literal); nothing else moves. The date above is when this version was
frozen and the bump landed, not when it reached npm; publication is a
separate, manually authorized step, and nothing in this file should be read
as evidence that it happened.

Fixed

• A record parked at the pre-0.7.0 default paused status "Blocked" could
  not leave it by any command after upgrading: task start and task pause
  refused the transition, task edit --status and task complete reported
  an unconfigured status, task demote had nowhere to go, and quest doctor
  reported the workspace healthy. QCLI-287 renamed the default to "Paused"
  and every lifecycle check compares the record's status to the configured
  value by exact string, so an already-parked record became an off-flow
  status on upgrade; 0.7.0's changelog warned about the literal and the
  best-placed consumer still missed it, so a warning was not the fix.

  quest task start <id> is now the sanctioned exit from the retired
  literal, exactly as it was in 0.6.x, when and only when the workspace does
  not configure "Blocked" itself (on its ladder or as its paused status);
  task pause then parks the record at "Paused". Nothing is migrated
  silently. quest doctor gains a task_status_off_flow issue naming every
  active task whose status is on neither the ladder nor the paused slot, with
  the repair command in its hint, so a stranded record is a red doctor
  rather than a healthy one. Reported by lore-web (LWEB-80), also hit by
  lore-cli (LCLI-333) (QCLI-302).

  For a stranded workspace, the repair is:

  quest doctor --json                      # names the task id and status
  quest task start <id> --actor <name> --actor-kind human --json

• The release publish no longer puts @opum-ai/quest on the registry until a
  read confirms all six platform packages actually resolve for a consumer.
  It previously ordered its writes and treated that as the guarantee; write
  order does not produce visibility order, and during the 0.7.0 publish the
  two disagreed in four of six positions while one package sat non-public for
  twelve minutes past the wrapper. Because platform packages are
  optionalDependencies, an install inside that window SUCCEEDS and leaves no
  binary -- so the failure was silent from the consumer's side and reported as
  success from the publisher's (QCLI-299).

  Nothing about an installed release changes; this is release tooling. The
  gate reads over plain HTTPS with no credential, which is a different client
  from the publishing one, and holds a 30s settle margin over the 9-20s
  publisher-early lag measured by opum-cli-e2e.

• A timed-out publish verification no longer asserts "this is registry
  read-after-write lag, not a failed release". That sentence was true of six
  packages and wrong about the one that decided whether 0.7.0 shipped, and it
  told the operator to stop investigating at the moment investigating was the
  whole job. It now reports each package's state read from the registry --
  public, staged, or undetermined -- and names the operator action for a
  staged one, including that the release token cannot clear it. The
  npm unpublish warning stays: that half was protecting against a genuinely
  destructive action (QCLI-299).

Added

• .github/workflows/lore-check.yml: CI now runs lore check on every pull
  request into dev (and on push to dev and main, so the context can later
  become a required check without deadlocking the fast-forward promotion). The
  operating block has made a green lore check the definition of done for a
  docs change all along; nothing here enforced it. Unlike the fleet reference
  job, this one installs no published @opum-ai/quest: lore's quest adapter
  shells out to whatever quest is on PATH, and this repository authors quest,
  so the job runs lore against a shim over bun run src/cli/main.ts from the
  same checkout and asserts that is what PATH resolved to (QCLI-301).