bubbles v0.3.0

Pairing that apps can manage themselves: reconnect as the same app, disconnect for real, cancel a request, and see the channels the bot is in.

What's new

Reconnect instead of a second app. An app that was paired before can name itself in its new pairing request. The admin sees "Replaces (@username)" and a "Reconnect as the existing app" box, ticked by default.
- The app keeps its bot, its username and its channels.
- Its old tokens stop working when it collects the new one.
- Pairing netdiag again no longer creates netdiag-2.
Disconnect. An app can revoke its own token. The next request with that token gets 401.
Cancel. An app can withdraw a pairing request it no longer wants. If the request was already approved but not collected, the new app is disabled.
Channels in the pairing answer. The answer that carries the token also lists the channels the bot is in, so the app knows where to post.
Approval form:
- "Also create a channel for this app" starts ticked when the app asks for alerts:write and no channel has that name yet.
- An existing public #<username>-alerts channel is reused.
- A warning shows when an alerts app would end up in no channel.
- Archived channels are no longer offered.
Docs:
- docs/netdiag.md now describes what netdiag v0.6 sends: severities, dedupe keys and the "Fixed at …" resolve note.
- The scopes table is fixed: listing alerts needs messages:read.

Anyone who can reach the onboarding port can open a pairing request that names any app id. The request alone grants nothing. A reconnect is only as safe as the admin's check: compare the six-digit code and the CA fingerprint as for a new pairing, and deny a reconnect you did not expect.
An enabled app's old tokens are revoked only when it collects the new token. An unclaimed or cancelled reconnect leaves them working. Reconnecting a disabled app revokes its old tokens at the approval itself.
Cancelling needs the request's poll secret. A wrong one gets 404, like the poll, and cancels share the poll rate limit (2 per second, burst 20, per IP).
Self-revoke needs the token itself and ends only that token.

Migration 0004 rebuilds pairing_requests. Every row is kept. It adds the cancelled state, replaces_app_id and replaced.
As with earlier migrations, the server first saves the database to backups/pre-migrate-3-4.db.
After the upgrade, a v0.2.x binary refuses to open the database ("database schema version 4 is newer than this binary supports"). To go back, restore that backup.
Apps built with the new Go SDK still pair with a v0.2.x server. The SDK leaves out replaces_app_id when the server refuses it. Cancel and self-revoke need v0.3.0.

Added:
- DELETE /api/v1/apps/self/token
- DELETE /api/v1/pairing/requests/{id} (with X-Poll-Secret)
Changed:
- POST /api/v1/pairing/requests takes replaces_app_id.
- The pairing poll answer that carries the token has channels: [{id, name}].
- The pairing state can be cancelled.
- The admin pending-pairing listing has replaces.
- The admin approve request takes replace_app.
- See docs/openapi.yaml.
Go SDK (pkg/bubblesclient):
- Pairing.Channels()
- Pairing.Cancel()
- Pairing.ID()
- Client.RevokeSelf()
- ErrPairingCancelled

Real phones.
Tray app on macOS and Linux.
Reconnect, disconnect and cancel from netdiag: netdiag v0.6.0 does not use these APIs yet.
See docs/field-checklist.md.