fix: KEEP-1051 prune stale doc pages, drop a version tag, and rename cmd/protocol

[suisuss]

Summary

Follow-up to #76, from reviewing the first sync it produced
(KeeperHub/keeperhub#1843). Making generation run was not sufficient to make
it correct: the reference still contained four pages for commands that no
longer exist, and one page published a version tag.

Three commits, one per issue.

1. Stale pages outlived their commands (81bd0b1)

GenMarkdownTree only writes; it never removes. So a page survives its own
command:

• kh_protocol.md, kh_protocol_get.md, kh_protocol_list.md - the command
  was renamed to plugin (Use: "plugin"), so cobra generates kh_plugin*.md
  and drops protocol from the index. The old pages stayed.
• kh_serve.md - serve is Deprecated, so IsAvailableCommand() is false
  and cobra skips it deliberately.

All four kept publishing commands that do not exist. A reader following
kh protocol list gets an error.

docs-check could not catch this, even after #76: an orphan's content never
changes, so it produces no diff. Clearing kh*.md before generating makes the
tree authoritative, so a removal now surfaces as a deletion.

72 -> 68 pages. Only kh*.md is swept; the hand-written guides and the
generator sources share that directory and survive.

2. Version tag in published docs (ca3e3e9)

kh wallet link help text said "v0.1.0 does not launch a browser session
handshake", published verbatim to docs.keeperhub.com. Version tags in published
docs go stale silently, and the sentence describes current behaviour rather than
one release's. Fixed at the source and regenerated - editing the page directly
would be overwritten by the next sync.

3. cmd/protocol -> cmd/plugin (f1167cd)

The package declared Use: "plugin"; the directory never followed. That
mismatch is why the orphans went unnoticed - generated pages were named after
the command, sources after its former name, so neither looked wrong on its own.

No behaviour change and no generated-docs change: the command has been plugin
all along, so regenerating produces an identical tree. That is the evidence it is
a pure refactor.

Verification

The point is not that the orphans were deleted, but that the guard can now catch
them, so I tested that directly:

• Planted a fake docs/kh_ghostcommand.md, regenerated -> it appears as D, so
  git diff --exit-code docs/ fails. Before this change an orphan produced
  no diff at all.
• Regenerating after the rename produces an identical tree, confirming commit 3
  changes nothing user-visible.
• go build, go vet, golangci-lint run ./... (0 issues), full
  go test -race ./... - no failures.

Downstream

KeeperHub/keeperhub#1843 still carries the four orphan pages and the v0.1.0
line, so it should not merge as-is. Once this lands and a release publishes, the
sync regenerates that content correctly - or #1843 can be closed and superseded
by the next automated sync, as #1842 was.