fix(server): subscription hardening — read-error subscription preservation + owner_id fence (PR #22 follow-ups)

[Calmingstorm]

Closes the two non-blocking NITs surfaced during PR #22's review.

1. Transient read error no longer drops live subscriptions

SubscribeAuthorizedStable called RemoveChannel on any read error, dropping the channel's entire subscriber set — including legit members a concurrent connect had installed — stranding already-connected clients until reconnect. It now returns the error and leaves the set intact (the caller broadcasts nothing; the committed row self-heals on the client's next channel-list fetch). RemoveChannel is kept only on the genuine !exists (deleted) path.

2. Migration 019 — fence owner_id updates

authorizedMemberIDs reads servers.owner_id, but migration 017 fenced the servers table on DELETE only. An ownership transfer (UPDATE servers SET owner_id) would change channel-visibility authorization without taking the exclusive per-server lock. No endpoint updates owner_id today, so the trigger fires never until one is added — at which point the create-vs-authz race is already closed. Future-proofing, zero current cost.

Tests

Mutation-verified pins for both: TestSubscribeAuthorizedStableReadErrorPreservesSubscriptions (realtime) and TestMigration019FencesServerOwnerUpdate (up/down trigger-event assertion). Full Go -race suite + gofmt/vet/golangci-lint green.

[Calmingstorm]

LGTM at 10eda697b838b1d4f61679884407dd6e5e749057.

I reviewed the complete PR #24 diff and found no blocking issues.

Verified:

• SubscribeAuthorizedStable now returns a transient authorization/existence read error without calling RemoveChannel, preserving the existing live subscriber set; the genuine !exists path still removes the channel.
• The read-error regression exercises the behavior directly and fails under the old teardown behavior.
• Migration 019 replaces the server DELETE-only trigger with BEFORE UPDATE OF owner_id OR DELETE, and the down migration restores DELETE-only behavior.
• In addition to the committed trigger-metadata regression, I ran a temporary PostgreSQL concurrency probe: an owner_id update blocked while the matching shared server-event fence was held, then completed after release.
• Migration 019 upgrade and rollback behavior passed against PostgreSQL 16.

Validation:

• Full Go suite with -race against PostgreSQL 16 and Redis 7
• Targeted regressions repeated five times
• go vet ./...
• gofmt and diff checks
• GolangCI with --new-from-rev=origin/main: 0 new issues
• GitHub Go, Lint, and Web jobs green
• PR is mergeable; exact checkout clean

PR #24 is ready to merge.