feat: carry a failing command's stderr snippet in the failed:<step> tag

[kurok]

Summary

The bootstrap phone-home tag (ec2-github-runner:bootstrap) only ever named
the step that failed (failed:<step>) — zero detail on why. This has cost
real debugging time (a #63-class bug, and an unexplained warm-restart-only
failure at the configuring step where the real config.sh error was
invisible without live SSH/SSM).

• gh_runner_phone_home_failed() (new, in PHONE_HOME_HELPERS) tees each
  shell's stderr into a scratch file and, on failure, appends a sanitized,
  single-line, ~150-char tail of it to the tag:
  failed:<step> → failed:<step>:<detail>.
• The scratch file is truncated on every successful step transition, so a
  step's detail only reflects that step's own commands (not noise left by an
  earlier || true-tolerated one, e.g. mount).
• The value is hard-capped at 256 chars (the EC2 tag-value limit) regardless
  of how much garbage a failing command emits, and control bytes/newlines are
  sanitized to a single printable line.
• Applied everywhere the phone-home pattern is used: buildUserData()'s
  outer + inner shells, buildReusableUserData()'s outer + inner shells, and
  its registerScript (per-boot re-registration for reuse: stop).
• src/wait.js splits on the first : after the failed: prefix to
  recover step vs. detail (step names never contain :, so this is
  unambiguous even when the detail itself has colons, e.g. a
  config.sh: error: ... line). Fully backward compatible with the old
  no-detail failed:<step> shape — error.bootstrapDetail is simply absent.

Before / after

# before
failed:configuring

# after
failed:configuring:config.sh failed: Not configured. Run config.sh to configure a runner.

A note on the tee race

tee's copy into the scratch file runs via a background process
substitution, so reading the file immediately in the ERR trap can race and
see it still empty. gh_runner_phone_home_failed() closes this shell's end
of that pipe (fd 2 — the script is terminating anyway) and polls (bounded,
~200ms max) for the tee process to exit via kill -0, which only happens
once it has drained everything written to the pipe. Verified empirically
against both bash 3.2 and bash 5.3 — deliberately not a plain wait on the
tee PID, since that needs bash >= 4.4 and could hang indefinitely if tee's
write end ever blocked.

Test plan

• tests/phone-home-detail.test.js (new): extracts the actual lines
  buildUserData() / buildReusableUserData() produce (outer root
  shells, both inner heredocs, and registerScript), splices in a
  fabricated failing command, and runs the result as a genuine bash
  script file against a fake curl (IMDS) + fake aws CLI — proving
  the real generated code truncates/sanitizes correctly, including one
  case with ~3.6KB of multi-line, control-character/ANSI-laden stderr,
  and a pathological ~50KB newline-filled case that must stay under 256
  chars with no embedded newlines. Also covers the backward-compatible
  no-detail case.
• tests/wait.test.js: detail surfaced in the thrown error, core.error,
  and error.bootstrapDetail; a detail containing colons splits
  correctly; backward compat with old-style failed:<step> (no
  bootstrapDetail, unchanged message).
• npm test — 237 passed, 18 suites.
• npm run lint — clean.
• npm run package rebuilt twice — byte-identical (sha256sum match),
  diff scoped to the src/aws.js / src/wait.js changes only.