Record private local signup request outcomes (#57)

docs/signup-facts.md

@@ -269,6 +269,34 @@ adapter fingerprint and blocks existing bindings for explicit reconciliation.
 Token rotation for the same account retains that fingerprint. Plan such changes
 as migrations; never reset a binding just to bypass the check.
 
+## Local signup request diagnosis
+
+The October 19 follow-up screenshot still shows the generic unavailable message
+after the network recovery. That screenshot alone does not establish a 503:
+the frontend also maps some rejected inputs and browser transport failures to
+that message. At the follow-up check the health endpoint returned 200, and BFF
+signup counters contained only the operator's two deliberately invalid probes.
+The user's current browser failure has not yet been reproduced or resolved.
+
+Local Caddy now logs requests to exactly `/api/v1/accounts/signup` under
+`http.log.access.signup`, including HTTP status and duration. The complete
+request object, response headers and user identifier are removed before log
+encoding, so paths/queries, cookies, authorization, addresses and user-supplied
+headers cannot enter these access records. Bodies are never logged. Other
+requests, including health probes and email confirmation URLs, are skipped.
+Inspect with:
+
+```sh
+docker logs --since 5m sxchnge-local-frontend-1 2>&1 |
+  jq -Rrc 'fromjson? | select(.logger=="http.log.access.signup")'
+```
+
+Validation: Caddy configuration validation and reload passed; a deliberately
+invalid signup returned 400 and produced the expected status/duration record.
+Sentinel query, cookie and custom-header values were absent from its log.
+The frontend was rebuilt with freshly resolved stable image pins. No real
+signup or customer email was submitted during this diagnostic work.
+
 ## Persistence, retries and recovery
 
 The local `signup_facts` collection uses the customer ID as `_id`, so its unique

infra/local/frontend/Caddyfile

@@ -5,6 +5,21 @@
 
 https://localhost:8443 {
 	tls internal
+	# Record signup status/timing even when the API rejects a request before
+	# account creation. Drop the entire request and response headers so URLs,
+	# cookies, addresses and browser-provided values cannot enter access logs.
+	log signup {
+		format filter {
+			wrap json
+			fields {
+				request delete
+				resp_headers delete
+				user_id delete
+			}
+		}
+	}
+	@otherRequests not path /api/v1/accounts/signup
+	log_skip @otherRequests
 	root * /srv
 	handle /api/* {
 		reverse_proxy bff:8082