expose health.fsck() as kb.fsck on MCP/JSONL/capabilities (roadmap 1.5)

[philluiz2323]

What you're trying to do

ROADMAP.md's 1.5 milestone: "vouch fsck — deeper consistency checks than
doctor." That check already exists (health.fsck(), wired as the vouch fsck CLI command) — but it's the one diagnostic sweep with no agent-facing
path: no MCP tool, no JSONL handler, not in capabilities.METHODS. An
agent can call kb.lint and kb.doctor but has no way to run the deepest
check (kb.fsck's own checks: orphaned embeddings, dangling
supersede/contradict chains, decided-proposal ↔ artifact mismatches,
index-vs-file drift) without shelling out to the CLI.

What you've tried

• Confirmed via grep across server.py, jsonl_server.py,
  capabilities.py: zero hits for kb_fsck, "kb.fsck", or an _h_fsck
  handler — health.fsck() is called from exactly one place,
  src/vouch/cli.py's fsck command.
• kb.lint and kb.doctor are registered on all four surfaces
  (server.py:kb_lint/kb_doctor, jsonl_server.py:_h_lint/_h_doctor,
  capabilities.METHODS, CLI lint/doctor) — kb.fsck is the one gap
  in that otherwise-complete trio.

Suggested shape

kb.fsck() — no parameters, mirroring kb.doctor's registration exactly:
MCP kb_fsck, JSONL kb.fsck, capabilities.METHODS. The CLI mirror
already exists (vouch fsck) and needs no change — kb.fsck's default
CLI-mirror name (kb.foo → vouch foo) already resolves to it.

Compatibility considerations

Purely additive — no VEP, no object model, on-disk layout, or existing
kb.* method change. health.fsck() itself is untouched; this only wires
its existing output to three more surfaces the same way kb.doctor
already does.

Alternatives

None considered — this closes an obvious, uncontested registration gap
rather than proposing new behavior.