API: enable it on gitbay.org, and document token onboarding without SSH #37

Blocks a native client (#11, #12).

/api/v1/cmd 404s on gitbay.org: the route is registered only when cfg.API.Enabled, and /etc/gitbay/config.toml has no [api] section. The entire JSON API is off in production, so no client can talk to it.

Two parts:

1. Set [api] enabled = true on bay1. Do this alongside rate limiting (#39) rather than before it — the surface is unmetered today.

2. Token onboarding. token create is SSHOnly and the 401 body says 'mint one over SSH', which is a dead end on a device with no OpenSSH. The principle holds — a token is a credential and should not be minted in a browser — so the answer is transfer, not relocation: mint on a machine that has ssh, then paste into the app. Pasting already works end to end once the API is on.

   Worth considering: token create --qr, printing the token as a QR in the terminal for the app's camera. Keeps the credential off the web entirely and reads as a CLI-first answer rather than an apology for one. Needs a small pure-Go QR dependency.

Done. [api] enabled = true is set on bay1 and the daemon restarted; /api/v1/cmd and /api/v1/read both answer in production. Rate limiting (#39) landed first, so the surface is metered.

Verified live: whoami, repo tree, repo cat, and a read-scoped token correctly refused a write with 403.

Token onboarding: pasting a token minted over SSH works end to end, which is the blocking path cleared. --qr is left open as an enhancement.