doctor: fix false blockers on mixed attribution, make --redact work, quiet the noise

[zzet]

Follow-up to #351 and #352, from the first real run of gortex doctor on a machine that had just upgraded. Four fixes, one of them a correctness bug that made doctor accuse a healthy install.

1. False blockers on mixed attribution (critical)

The attribution guard from #352 was all-or-nothing: the union stood in only while no row carried an agent. But a log is not attributed or unattributed — it is mixed, for as long as the window still reaches back past the upgrade. One attributed row flipped the summary to strict mode and hid every older row behind it.

PreToolUse fires constantly and attributed itself within minutes. SessionStart fires once per session and had not run again yet. On a working install:

✗ BLOCKER SessionStart is configured but never ran, while other hooks did (not once, ever).
✗ BLOCKER UserPromptSubmit is configured but never ran, while other hooks did (not once, ever).
✗ BLOCKER PostToolUse is configured but never ran, while other hooks did (not once, ever).

…against 17,317 rows in the same window saying otherwise, and beside a last seen of never for an event that had last run twenty minutes earlier. The guard meant to prevent that accusation is what produced it — the tests covered the two clean states and never the transition every machine passes through.

Unattributed rows are now rolled up per event and held out of every agent's counts rather than shared into all of them:

agent runs	unattributed runs	verdict
> 0	any	normal analysis
0	0	genuine silence → blocker
0	> 0	cannot tell → withheld, reported as INFO

The table gains an unattrib column so a zero explains itself, and dates the last run from unattributed rows when that is all there is — never beside evidence of 48 invocations is a contradiction, not a diagnosis.

The regression test reproduces the reported machine state and fails against the previous rule with all three false blockers verbatim.

2. --redact was a no-op

It promised to hash repo paths and branch names, and rewrote only Adoption fields the human report never renders — while printing every absolute path, repo name and account name included, in both sections. Paths under the repo root now render as <repo>/… and under home as ~/…, installed before anything renders so the static report, the runtime report, the paths quoted inside findings, and --json all agree. Branch names are not paths and can carry a ticket or customer name, so they are hashed.

3. ✗ on optional files read as an accusation

Every per-repo file gortex init had not written was marked ✗, implying work the user has to do. It is not: a machine configured by gortex install needs no repo-local config, and most repos never get any.

  ✓ present   · absent (optional — repo-local config)   ! needs attention

  [✓ installed] [✓ gortex files]  claude-code
      · <repo>/.mcp.json (optional — `gortex init` would create)
      ✓ <repo>/.claude/settings.local.json (26774 bytes)

A stale MCP stanza previously shared the ✓ of a healthy file with the explanation buried in a trailing note. It is a real gap and now reads as one (!). The header's any-file-present becomes gortex files, which is what it always meant.

4. Uninstalled adapters buried the machine

All twenty adapters were listed with full planned-file sets regardless of installation — one uninstalled agent contributed twenty-one SKILL.md paths for writes that will never happen. Adapters that are neither installed nor holding Gortex files now collapse to a name list; the section drops from 113 lines to 56.

An absent agent that still holds Gortex files is kept and labelled leftover config — that is a finding, and a blanket "hide undetected" filter would have swallowed it.

--all restores the full listing. --json stays complete either way: a machine consumer has no scrolling problem, so filtering there would only lose data.

Tests

Seven new cases. The load-bearing ones:

• mixed attribution does not accuse — reproduces the reported state; verified it fails against the old rule with the three false blockers verbatim.
• attributed silence still blocks — the guard must not swallow the finding it exists to protect.
• wholly ambiguous window reports uncertainty — INFO, not a blocker, not silence.
• ✗ reserved for real gaps — absent-optional vs present vs outdated vs unreadable.
• collapse + --all round trip, and leftover config survives the collapse.

go build ./..., go vet ./..., go test ./cmd/gortex ./internal/doctor ./internal/hooks green.

[zzet]

Added: gortex upgrade now does the migration itself

2f707b71. The [outdated stanza: run gortex install to migrate] remedy was handing back a chore at the wrong moment — upgrading is exactly when configs should be brought current, and the user already asked for the new version.

gortex upgrade --run now re-applies agent config after the binary lands, and the closing advice no longer names a step it just performed:

Next:
  gortex index .    # reindex so the graph picks up extractor changes

versus a dry run, which still owes it:

After upgrading:
  gortex install    # refresh agent config for the new version
  gortex index .    # reindex so the graph picks up extractor changes

--no-migrate opts out, and says so rather than skipping silently. Doctor's remedy now reads [outdated stanza: gortex upgrade --run migrates it, or gortex install].

Two constraints worth flagging in review

It must re-exec the new binary. The running process is the old one — the package manager replaced the file underneath it — so re-applying adapters in-process would faithfully write the shapes the upgrade exists to migrate away from. It resolves through PATH first, because go install can land the new binary somewhere other than where the old one ran from; re-execing the stale path would be the same bug wearing a different hat.

It goes through gortex install, not a quieter bespoke migrator. Re-applying can rewrite a hook definition, and Codex records trust against each hook's hash — a changed hook is skipped until re-approved in /hooks. That is the failure #348 was about, and an upgrade that silently reintroduced it would be worse than the chore it replaced. The install summary already carries the trust notice, so routing through it means the migration cannot quietly un-trust anything.

The refresh is best-effort: the binary has already been replaced by then, so a refresh that cannot run is a warning with a manual command, never a failed upgrade.

Tests

• re-exec target is absolute and runs a non-interactive install — the sequencing assertion.
• a failed refresh warns with a manual command and does not fail the upgrade.
• follow-up advice lists the config step only when it was not performed.

go build ./..., go vet ./..., go test ./cmd/gortex — 732 tests green.