control: wiki has no commands — the web is the only surface that can read it #48

A repository's wiki lives in a companion bare repo at <owner>/<name>.wiki, and internal/httpd/wiki.go reads it with gitutil.ListTree and gitutil.ReadBlob against that directory. The companion is not registered in the store, so it is not reachable as a repository either: repo tree krz/gitbay.wiki answers "repository not found".

The result is that wiki content is readable only in a browser. The CLI cannot list or print a page, the JSON API cannot serve one, and a native client cannot show one — the same shape as blame (#42), file editing (#43) and single commits, each of which turned out to be a capability stranded behind the web because the handler went around the registry.

This is the fourth instance, which suggests the rule needs enforcing rather than repairing case by case. A test that walks the registered web routes and asserts each read handler dispatches a command would catch the next one at the point it is written.

For the capability itself, wiki pages are just files in a git repo, so the smallest thing that works is to let the existing commands see the companion:

• repo tree <owner/name>.wiki and repo cat <owner/name>.wiki <page> — that is, register the companion so resolveRepo finds it, inheriting the parent's visibility and access. No new commands, and clients get listing and reading for free.
• Or explicit commands: wiki list <owner/name>, wiki show <owner/name> <page>.

The first keeps the surface smaller and matches how the wiki is already edited: by pushing to <repo>.wiki.git, which is ordinary git.

Found while auditing iOS parity against the web's routes; /{owner}/{repo}/wiki is one of the routes with no counterpart anywhere else.