A wiki should live in the repository, not a companion repo #170

A wiki is a companion bare repo at <name>.wiki.git, created on first push, with no store row — access derives from the parent. Costs that follow:

• Invisible to the store. Backup verification cannot tell a wiki from a leaked directory and says so (cmd/gitbayd/backup.go:270); quotas, repo list, search and the activity feed are all blind to it.
• Push is the only write path. There is no wiki edit, and the web renders wikis read-only. It is the one capability that does not follow "the capability lands as a control command, then the surfaces render it".
• .wiki is a permanently reserved repository-name suffix (internal/policy/names.go:62).
• A second clone URL nobody can discover without knowing the convention.

Move pages to .gitbay/wiki/ on the default branch, beside ci.yml and CODEOWNERS. One repository, one clone, one backup, one permission model, and repo commit-file already provides web editing for repositories that permit server-authored commits.

The companion path goes away entirely: the .wiki branch in sshd.go, wikiDir in control and httpd, the name reservation, the rename and delete handling in repo.go, and the backup special-case.

Depends on #169 for path filters — without them every prose commit runs the full suite.

One wiki exists on the instance (krz/gitbay), so migration is git subtree add --prefix=.gitbay/wiki, done once by hand, preserving its history.