[Feature]: [P3] Redact player-authored free text (tower names) from $exception messages

Deferred from the cookieless error-tracking bmad-code-review (Acceptance Auditor, soft finding).

analyticsErrors.ts bounds an exception message to 500 chars and the raw stack to 2000 before sending $exception through the relay. Length-bounding caps payload SIZE, not sensitivity: if game code interpolates a player-authored tower name into a thrown error message (uncommon but possible), that free text is forwarded verbatim within the bound.

Why it is acceptable as-is (not a merge blocker): there is no IP (the relay disables GeoIP and forwards none), no persistent id, and no cross-session linkage, so a leaked free-text string is bound to no stable identity and does not de-anonymize. The vector is narrow (only if code throws with an interpolated name).

Follow-up when picked up: scrub known player-authored fields from the outgoing value/stack before send. Options:

• Maintain the tower name(s) currently in play and redact any occurrence from the message/stack (replace with a placeholder like <tower-name>).
• Or, more broadly, allowlist-scrub: only forward the exception type and a fingerprint plus a redacted message, if the residual value of full messages is judged not worth the free-text risk.

Pairs naturally with the other error-tracking follow-up: structured stack-frame parsing plus a source-map upload (so PostHog Error Tracking resolves frames instead of showing the raw string). Both were deferred from the same first version.

Start in analyticsErrors.ts, where exception values and raw stacks are length-bounded before the $exception relay send. Decide whether to redact active tower names or allowlist the forwarded fields, then verify that player-authored text is absent from both value and stack while the existing size limits remain intact.