Surface marker scan health in the rendered PR comment, not just the Action log

[mbeacom]

Follow-up from the review of #106. Shipped in v0.5.0.

The gap

renderComment never reads outcome.markerScan. The absent / unreadable / out-of-tree distinction — the entire ADR-0016 reason those states exist — lives only in a core.info count line at packages/ci/src/action.ts:90-94.

So on the surface that matters most, "found nothing" and "could not look" render identically. adr check on the CLI does distinguish them (marker scan unavailable for: …); the PR comment does not.

The trigger is mundane, not adversarial

Any workflow where GITHUB_WORKSPACE is not the PR head tree:

• actions/checkout with ref: overridden (e.g. checking out main)
• actions/checkout with path: set, while the scan root stays $GITHUB_WORKSPACE (packages/ci/src/index.ts:34,40)
• a sparse or partial checkout
• a monorepo layout

In every one of these the corpus loads perfectly and affects matching works perfectly. Only the marker half goes dark. A maintainer who did not write adrkit sees a normal-looking comment with decisions quietly missing and no in-comment cue that anything was skipped.

Shape of a fix

A bounded, corpus-authored one-liner when counts.absent + counts.unreadable + counts['out-of-tree'] + counts.skipped > 0.

Two constraints:

• It must stay non-blocking. Markers gain no exit-code authority under ADR-0022, and a scan-health line must not change that.
• It interacts with the comment budget tuned in feat(core,ci): wire inbound @adr markers into check #106. Changed-record validation errors render first and have priority under truncation; a scan-health line must not be able to displace them.

Also in scope: README.md and site/src/content/docs/ci.mdx both show a bare actions/checkout@v4 with no caveat about the scan root.

Related: #111 (the same "could not look" vs "nothing there" shape, on the queue side).