fix(bgrun): discourage polling a job you just started

[lloydsk]

What

Every measured session that used bgrun opened the same way — bgrun, then bgstatus, then bgtail — before the job could possibly have finished. In one run those two calls were 2,231 of 8,049 context chars (28%), spent learning what the wake delivered for free moments later.

Nothing told the agent not to: the guideline mentioned the wake only in passing, the started: result said merely "You'll be woken automatically when it finishes", and the run-bg skill licensed the polls in two places:

• step 2: "exit: 0 → success. bgtail to confirm." — a read even when the wake already carried the counters;
• step 3: "If you need to check before the wake (non-blocking): call bgstatus…" — framed as ordinary practice.

Change

• BGRUN_GUIDELINES gains: "Do not poll a job you just started — no bgstatus/bgtail round after bgrun: the wake is the signal and carries the outcome (exit code, stats, the log's last line, and the digest when the project configures one). Read the log only when the wake is not enough — typically the detail behind a failure."
• The started: result ends "…no need to poll; the wake carries the exit code, the stats and the log's last line."
• Skill step 2 makes the wake itself the result and drops "bgtail to confirm"; step 3 is reframed — checking before the wake is rarely worth it, so reach for bgstatus when the job is not one you just started (another session's, one from before a restart, or one whose wake never came).
• The completion wake's own trailing instruction is now conditional — see below; it was the strongest polling invitation in the system.

The bgtail/bgstatus descriptions are deliberately untouched: they describe what those tools do, not when to reach for them.

Follow-up from review (second commit)

The first commit left the contradiction in place: the wake still ended with an unconditional

Review the result now: call `bgtail` with this job id to see the output, summarize pass/fail, and continue the task that depended on it.

…emitted on exit: 0 as well. That is the last instruction the agent reads on every completion, and it asks for exactly the read this PR discourages. The smokes could not catch it — one-shot sessions exit before the wake arrives, so they only measure the pre-wake decision.

Fixed:

• the wake ends with the success wording ("…are the result — report it…") or the failure wording ("Analyze the failure: bgtail … bggrep …"), never both;
• the ❌ test pins the failure wording and the absence of the success wording;
• digestBlockOf no longer delimits the digest block by that instruction's wording (it broke four digest tests), and the README sample (an exit-1 job) shows the failure variant;
• the guideline and started: line no longer claim the wake carries the line count, last line and digest unconditionally — each is conditional in the wake construction.

Verification

• tsc --noEmit clean; 224 tests pass, including the new failure/success wake assertions.
• Two live smokes asking an agent to start a job — one with skills disabled, one with the skill loaded — each make exactly one call (bgrun) and answer "I'll be woken when it finishes", where every earlier arm polled twice.
• The wake's two instruction variants are pinned by tests rather than by a smoke, which is the lesson of the follow-up above.

[github-actions]

CI report

Check	Result
tsc --noEmit	success
tests	success
npm pack --dry-run	success (7 files in tarball)

Ref: 0baa23b0e69ea81fae882014d31c083d0a076677