docs(auth): correct the claim that QA could never run Google sign-in

It can, and it does. Registering the QA callback under Authorized redirect URIs was all it took.

The claim was that qa-redefined-designs.bermudalamb.synology.me could never be registered, because Google requires a redirect URI's host to sit under a domain whose ownership has been proved by DNS, and Synology owns the domain above that one. It was inferred from #285, where Cloudflare's free tier genuinely cannot be applied to that hostname, and asserted with far more confidence than the inference supported. What was actually established is narrower: localhost is exempt from the authorized-domain rules, and a domain listed as an authorized domain has to be verified in Search Console. Whether either applied here was never checked.

It was not a harmless error. On the strength of it, QA testing of this feature was documented as blocked behind #313, the QA compose file hardcoded its credentials to empty rather than reading the stack, #345 recorded it as a constraint, and #332 closed with it written into the summary. A QA deploy was spent on it.

So the correction is left in place rather than the wrong sentences quietly deleted. A document that silently stops saying something teaches nobody why it said it, and this is the second time in this feature that a confident inference about somebody else's platform has cost a day — the first being the assumption that a passing local build said anything about another machine.

What replaces it is the thing that was always true and never written down plainly: every environment sends a redirect URI derived from its own PUBLIC_URL, and each one has to exist verbatim in the console. There is now one table listing all four, including the localhost:5173 entry that local development needs and that Phase 0 originally omitted — the omission that cost an hour of redirect_uri_mismatch before any of this.

The QA compose comment now says which URL to register rather than why it cannot be. The ops document gains the steps QA actually took, in order, with a note on why registering before setting the variables is the order that matters: a button that appears before its callback exists fails at Google, where nothing in the storefront logs explains it.

Verified: backend tsc clean, the QA compose file still parses, and no file in the tree still claims the hostname is unusable.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docker-compose.qa.yml

@@ -65,12 +65,10 @@
 #                     production's: a link signed with it acts without a login.
 #   QA_GOOGLE_CLIENT_ID — optional, and all-or-nothing with the secret below:
 #   QA_GOOGLE_CLIENT_SECRET  setting one without the other refuses to boot
-#                     (#340). Both unset means the Google button is simply not
-#                     offered, which is the right answer while QA lives on a
-#                     *.synology.me hostname — Google will not accept a redirect
-#                     URI whose domain nobody can prove they own, so a button
-#                     there could only ever fail. Set them once QA moves to
-#                     qa.redefined-designs.com (#313, #345).
+#                     (#340). Both unset means the Google button is not offered
+#                     at all, which is the right answer until QA's callback URL
+#                     is registered in the Google Auth Platform. See the note
+#                     beside the values themselves for the exact URL (#345).
 #   QA_REMBG_URL — optional. The background-removal sidecar, e.g.
 #                     http://rembg-syn:7000. Unset turns the feature off rather
 #                     than breaking anything. The sidecar must be on the same
@@ -208,16 +206,21 @@ services:
       # odd one out and cost a QA deploy: the variables were set on the stack,
       # nothing read them, and the button stayed missing with no explanation.
       #
-      # Leave them UNSET until QA moves off *.bermudalamb.synology.me. Google
-      # refuses a redirect URI whose host is not under a domain whose ownership
-      # has been proved by DNS, and nobody can prove ownership of that one,
-      # because Synology owns the registrable domain above it — the same wall
-      # #285 hit. Setting them today produces a button that fails at Google with
-      # redirect_uri_mismatch, and no console entry can satisfy it.
+      # Setting these needs one thing done first: the QA callback registered
+      # under Authorized redirect URIs for this client in the Google Auth
+      # Platform, exactly as it appears below. Google compares the two as
+      # strings and answers a mismatch with redirect_uri_mismatch.
       #
-      # Once #313 moves QA to qa.redefined-designs.com: set these two, point
-      # PUBLIC_URL at the new host, and add the matching callback under Clients
-      # in the Google Auth Platform. No code change either way (#345).
+      #   https://qa-redefined-designs.bermudalamb.synology.me/api/auth/google/callback
+      #
+      # An earlier version of this comment said that URI could never be
+      # registered, because Synology owns the domain above it. That was wrong,
+      # and the correction is left here rather than removed: it was inferred
+      # from #285, which is a related but different problem, and it put QA
+      # testing of this feature behind #313 for no reason.
+      #
+      # When #313 moves QA to qa.redefined-designs.com, point PUBLIC_URL at the
+      # new host and register that callback too. No code change either way.
       - GOOGLE_CLIENT_ID=${QA_GOOGLE_CLIENT_ID:-}
       - GOOGLE_CLIENT_SECRET=${QA_GOOGLE_CLIENT_SECRET:-}
     volumes: