fix(runner): report skipped concurrent instances as skips, not passes

[monikon22]

Under concurrency: N, a describe.serial block that stops early on some of its
instances reported the positions those instances never reached as passes. Below
is the shape of a real 10-bot run, with the plugin's names replaced:

  FAIL  Claims > rejects a claim on an already claimed chunk   5.0s [7/10]
    10 instances: min 0ms / avg 1.5s / max 5.0s
      - [4/10] ?: OK (0ms)
      - [5/10] pw_418a: FAIL (5.0s) Expected message matching "Already claimed" not received
      - [6/10] ?: OK (0ms)

Instances 4 and 6 had stopped at an earlier test in the block and never ran this
one. They still counted toward 7/10, printed as OK (0ms), dragged the min
down to zero, and had no name to show. The summary said Skipped: 0 for the
whole run.

What changed

TestInstanceResult gains skipped and skipReason, and aggregateInstances
copies them off the per-instance TestResult instead of dropping them. Skip rows
from a serial block now carry the bot's username too — that's where the ? came
from.

The reporter reads the flag:

  FAIL  Claims > rejects a claim on an already claimed chunk   5.0s [5/8, 2 skipped]
    8 instances ran, 2 skipped: min 50ms / avg 1.9s / max 5.0s
      - [4/10] pw_7e4e: SKIP serial block "Claims" stopped at "grants the claim permission"
      - [5/10] pw_418a: FAIL (5.0s) Expected message matching "Already claimed" not received
      - [6/10] pw_d411: SKIP serial block "Claims" stopped at "grants the claim permission"

The ratio is over the instances that ran. Duration statistics skip the zeros. A
skipped instance shows its stop reason and no duration, because (0ms) next to a
skip is the exact thing that read as an instant pass.

A test row only counts as skipped when every instance skipped it, so
Skipped: alone can't show this. The console summary and
summary.skippedInstances in the JSON report now carry the instance count.

Also here

toHaveReceivedMessage failures quote the last 10 lines of the buffer they
searched, or say outright that nothing arrived. "Expected message matching
Already claimed not received" reads identically whether the server answered
something else or stayed silent, and on a live server that is the difference
between a throttled command and a plugin bug.

Verification

npm run typecheck and npm run build in runner-package. Reporter output
checked against a synthetic result reproducing the run above; JSON report
inspected for the new fields. No behavioural change to test execution — this
touches how results are recorded and printed, nothing about what runs.

[Drownek]

Great catch, clean implementation.

What I checked:

• Instance reporting: propagating skipped and skipReason through aggregateInstances fixes the false-positive pass counts. [7/10] now shows as [5/8, 2 skipped], which is correct.
• Duration stats: ranInstances() keeps (0ms) skipped placeholders out of the min/avg calculations, so they no longer drag the numbers down.
• Bot attribution: passing botUsername on skipped serial positions gets rid of the anonymous ? in failure traces.
• Assertion diagnostics: quoting the trailing 10 lines of the message buffer in toHaveReceivedMessage (or saying outright that nothing was received) makes it way easier to tell whether a command got throttled or the plugin just replied with something unexpected. Good call.
• JSON reporter schema stays backwards compatible — summary.skippedInstances is purely additive.

Ran it locally across a few concurrent runs, no issues.

LGTM