CORE-410: cherry-pick auth + repetition fixes from Zambia fork

[nraffa]

Summary

Brings the authentication and skills-explorer repetition fixes developed on the Zambia fork over the past months into core Compass. Each change is an atomic cherry-pick -x (provenance trailer preserved); fork-only features were deliberately excluded.

Resolves CORE-410.

Changes

Authentication

• Remove client-side token expiry/iat checks — rely on server 401 to handle device clock skew (01b41a60)
• Retry token refresh on network errors (30f36852)

Skills-explorer repetition / disengagement (the core of the ticket)

• Runtime repetition detection + force-summarization (_flush_if_repeating, REPETITION_SHORT_CIRCUIT_THRESHOLD) (a486465b)
• Prompt-level NEVER re-ask + DISENGAGEMENT SIGNALS rules, wrapped around core's existing (a)/(b)/(c) question structure (3679765d)
• Don't persist the outgoing agent's response on phase transition — the incoming agent produces the message the user sees (23341141)
• Sentence-decomposition grammatical-person consistency (15b0b771)
• Scripted loop-detection eval tests replaying real production transcripts (daf74094)

Config

• Split VERTEX_API_REGION → VERTEX_API_EMBEDDINGS_REGION + VERTEX_API_GEN_AI_REGION (embeddings models need their own regional endpoint) (6c00932a)

⚠️ Deploy prerequisite — VERTEX_API_* migration

embeddings_model.py hard-raises if VERTEX_API_EMBEDDINGS_REGION is unset (gen-AI only warns + defaults to us-central1). In-repo templates are updated, but before deploying to any environment both new vars must be added to: GitHub Actions secrets, Pulumi config/ESC, and each Cloud Run env (plus every dev's local backend/.env). Backend will not boot otherwise. Do not merge with [pulumi up] until external envs are updated.

Adaptations from upstream (intentional divergences, noted in commit bodies)

• API Gateway rate limit set to 1200 req/min (upstream raised to 3600) to match core's traffic profile
• Prompt restructure keeps core's existing questions — no achievement/challenge question added (upstream 3fb9fb60 skipped for that reason)
• Transition fix trimmed of fork-only counseling sub-phase / sticky-routing / observability infra

Follow-ups (non-blocking)

• Tighten expect_errors_in_logs=True to assert on the specific expected error
• Enable the xtest Firebase retry tests (parked upstream due to fake-timer issue)
• Add a deterministic unit test for _flush_if_repeating boundary cases

[sentry]

Bug: In _flush_if_repeating, trimming answers_provided to [:new_len] creates an off-by-one error, breaking the invariant that len(answers) should be len(questions) - 1.
_{Severity: MEDIUM}

Suggested Fix

In _flush_if_repeating, when trimming the answers_provided list, adjust the slice to [:new_len - 1]. This will correctly maintain the invariant where the number of answers is one less than the number of questions.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI
agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's
not valid.

Location: backend/app/agent/explore_experiences_agent_director.py#L474-L479

Potential issue: The `_flush_if_repeating` method incorrectly trims the
`answers_provided` list, causing an off-by-one error. The code is intended to maintain
an invariant where `len(answers) == len(questions) - 1`. However, when the `questions`
list is deduplicated to a `new_len`, the `answers_provided` list is also trimmed to
`new_len`. This makes both lists the same length, breaking the invariant. Consequently,
when the final user answer is appended later, it is dropped by `zip(questions,
answers)`, leading to data loss for downstream tasks.

_{Did we get this right? 👍 / 👎 to inform future reviews.}