…ulates (#3714)

* fix(seed-portwatch): lower temp gate 25→20 so cap-mode rotation accumulates

WM 2026-05-16 observation (post-PR-#3711 first real-data run):
- Cap-mode cold-fetched 30 countries, 22 succeeded (~73%), 8 errored with
  the real "Invalid query parameters" upstream signal
- COVERAGE GATE failed at 22 < 25 → extendExistingTtl-only → 22 fresh
  successes were NOT written to Redis
- Net effect: each run restarts from 0 cache-fresh, rotation never
  accumulates, full-coverage convergence never happens

Root cause: the temp gate at 25 was set on 2026-05-14 when we had zero
visibility into the actual success rate. PR #3711's budget rebalance now
produces a stable ~22/30 success rate, just shy of the gate.

Fix: lower the temp gate 25 → 20. A 22-success run now persists, the
22 fresh countries become cache-fresh (asof = upstream maxDate), next
run skips them via the cacheHits path, and cap-mode picks a different
30 from the remaining 152. Projected convergence:
  Run 1: 22 fresh persisted
  Run 2: 22 + 22 = 44 cumulative
  ...
  Run 8: ~174 ≈ full coverage (~4 days at 12h cadence)

Caveats noted in the comment:
- If upstream maxDate advances between runs, all cached entries become
  stale (`Cache: 0 hits, 174 misses`) and rotation restarts from 0
- Revert path: bump to 30 when single-run success rate exceeds 90%
  (≥27/30), back to 50 once upstream stable enough for non-cap-mode runs.
  Target review: 2026-05-22

Tests:
- 1 existing test updated: assert MIN_VALID_COUNTRIES=20, "TEMPORARILY
  lowered" + "Revert path" comment markers (slightly relaxed from the
  pre-existing specific "from 50" and "to 50" so future bumps don't
  require fresh test edits)
- 99/99 portwatch tests pass
- 8853/8853 npm run test:data pass

* review: preserve 'was 50' baseline anchor in temp-gate canary test (P2)

Greptile PR #3714 P2: my relaxation of the MIN_VALID_COUNTRIES canary
test from /TEMPORARILY lowered from 50/ → /TEMPORARILY lowered/
removed the explicit anchor to the original permanent baseline (50).
A future editor writing a vague 'TEMPORARILY lowered for now' could
silently pass CI and lose the 'don't forget this is temporary' property.

Re-tighten with one anchor to the historical baseline (per Greptile's
suggested patch). The existing comment already says 'was 50 → 25 on
2026-05-14', so the test passes without further source changes.

Test-only change. 99/99 portwatch tests pass.

…p proxy short-circuit (#3760)

* fix(seed-portwatch): bump direct timeout 15→30s, lower gate 20→5, drop proxy short-circuit

WM 2026-05-18 — three composable changes after re-measuring ArcGIS
behavior and analyzing the post-#3714 run logs:

═══════════════════════════════════════════════════════════════════
1. FETCH_TIMEOUT 15s → 30s (PROXY_FETCH_TIMEOUT 70s → 50s)
═══════════════════════════════════════════════════════════════════

PR #3711's 15s direct timeout was sized for "Railway-direct never
returns" (pre-fix evidence: 100% timeout at 45s). Today's live
residential laptop probe on today's failing-country set shows ArcGIS
actually responds in 1.8-28.4s:

   JPN 1.8s ✓    USA 8.0s ✓    KWT 17.3s  ← killed by 15s
   CHN 3.9s ✓    POL 9.2s ✓    PAK 18.0s  ← killed by 15s
   SLB 4.8s ✓    VIR 16.6s ← killed
   SEN 7.0s ✓    CMR 18.1s ← killed
                 BHS 26.1s ← killed
                 PRT 28.4s ← killed

6 of 12 fetches (50%) exceed 15s — each gets killed and routed through
the slower degraded proxy, where many fail with Decodo CONNECT 522s.
30s covers ~95% of the observed range with PRT (28.4s) as the only
edge case. Rebalanced PROXY_FETCH_TIMEOUT 70→50s to keep per-country
budget under wrap: 30 + 50 = 80s ≤ 90s with 10s slack.

═══════════════════════════════════════════════════════════════════
2. MIN_VALID_COUNTRIES 20 → 5
═══════════════════════════════════════════════════════════════════

Three consecutive post-#3714 runs landed 6/8/10 fresh successes —
all failed validation at gate=20, all triggered extendExistingTtl-only.
Net effect: fresh successes were NEVER written to Redis, so the
cap-mode rotation never accumulated and every run restarted from 0
cache-fresh (\`Cache: 0 hits, 174 misses\` every single run).

Floor at 5 matches MIN_FRESH_FETCH_FOR_CAP_BYPASS (the load-bearing
silent-loss safety from PR #3711). Cap-mode bypass still requires 5
fresh upstream contacts before publishing, so the "everything-stale"
scenario still trips the 80% guard. The validateFn lower bound is
the only thing changing; the silent-loss surface stays the same.

═══════════════════════════════════════════════════════════════════
3. Remove "via proxy after" short-circuit in fetchWithRetryOnInvalidParams
═══════════════════════════════════════════════════════════════════

PR #3701 P2 added \`if (/via proxy after/i.test(msg)) throw err;\`
assuming proxy responses were authoritative — same query via proxy
twice would give same result. Live laptop probe disproved this:

   SLB attempt 1: OK 189 features (10.2s)
   SLB attempt 2: Proxy CONNECT: 522 (3.1s)
   SLB attempt 3: OK 189 features (8.6s)

Non-deterministic upstream + Decodo gate flakiness means proxy
retries DO recover. Today's logs show ~6 errors per run with
"Invalid query parameters via proxy" on countries that succeed when
I probe them right after — those would now recover via the retry.

INVALID_PARAMS_RETRY_THRESHOLD=5 still caps the total per-run
budget impact during full-degradation episodes.

═══════════════════════════════════════════════════════════════════

Tests:
- 98/98 portwatch-port-activity-seed tests pass
- typecheck clean
- 3 existing tests updated for new constants (FETCH_TIMEOUT=30_000,
  PROXY_FETCH_TIMEOUT=50_000, MIN_VALID_COUNTRIES=5)
- "proxy-confirmed Invalid query parameters short-circuits the retry"
  test INVERTED to assert the short-circuit is now ABSENT
- "threshold check fires BEFORE proxy short-circuit" test REMOVED
  (the short-circuit it tested ordering against is gone)
- Test:data shows 134 pre-existing failures in unrelated files
  (mcp-jmespath, brief-carousel) — confirmed against origin/main,
  not caused by this change.

* review: decouple per-country writes from canonical advance (P1) + restore proxy short-circuit (P2)

Greptile PR #3760 round 2 — both findings addressed.

═══════════════════════════════════════════════════════════════════
P1 — gate=5 alone could publish a 5-country canonical as healthy
═══════════════════════════════════════════════════════════════════

Pre-fix: lowering MIN_VALID_COUNTRIES to 5 let a 5-country fresh-fetch
run pass validateFn, earn the cap-mode bypass, advance the canonical
list, and clear the operator WARNING — exposing consumers to a 3%
coverage canonical published as fresh. The reviewer also noted that at
the observed 6-10/run success rate, the rotation may not reach full
coverage before MAX_CACHE_AGE_MS (7d) ages out the early entries.

Fix: decouple per-country writes from canonical/meta advance.

  Per-country writes (KEY_PREFIX${iso2}):
    Gate at MIN_VALID_COUNTRIES = 5  → cache-fresh rotation can
    accumulate even during slow recovery.

  CANONICAL_KEY + META_KEY:
    Gate at MIN_CANONICAL_PUBLISH = 50 (new constant) → operator-facing
    healthy signal only flips when coverage genuinely recovers.

Below the canonical floor: extendExistingTtl preserves prior canonical
+ meta, and a new "PARTIAL PERSIST: N/50 below canonical-publish floor"
log line surfaces what happened. Consumers reading the canonical list
still see the prior 174 countries with their existing data (mostly
stale for not-yet-rotated entries, fresh for the ones we just wrote).

═══════════════════════════════════════════════════════════════════
P2 — Proxy retry burns budget the per-country wrap won't honour
═══════════════════════════════════════════════════════════════════

Pre-fix: removed the `if (/via proxy after/i) throw err` short-circuit
based on a standalone laptop probe showing proxy retries DO recover.
But inside the seeder's 90s per-country wrap, by the time we hit this
catch we've already used direct(30s) + proxy(50s) ≈ 80s. The retry's
500ms backoff + new direct+proxy can't fit in the ~10s remaining
before the wrap aborts.

Restored: keep the short-circuit. INVALID_PARAMS_RETRY_THRESHOLD still
ticks for global visibility.

═══════════════════════════════════════════════════════════════════

Tests:
- 99/99 portwatch-port-activity-seed tests pass
- typecheck clean
- "proxy-confirmed Invalid query parameters short-circuits the retry"
  test re-inverted to assert short-circuit is BACK
- New test: canonical/seed-meta advance gated on MIN_CANONICAL_PUBLISH
- MIN_VALID_COUNTRIES canary test updated (no longer asserts the
  literal "TEMPORARILY lowered" phrase — the structural anchors
  (Revert path + was 50 + MIN_CANONICAL_PUBLISH reference) carry
  the canary intent)

* review: extend prevCountryKeys in PARTIAL PERSIST path so prior payloads don't expire (P1)

Greptile PR #3760 round 3 P1: the new partial-persist branch I added
in round 2 only extended CANONICAL_KEY and META_KEY:

  await extendExistingTtl([CANONICAL_KEY, META_KEY], TTL).catch(...)

That left the per-country payload keys for UNTOUCHED countries (i.e.
the ones not refreshed this run, still referenced by the preserved
canonical list) at risk of TTL expiry (TTL=3d) during a multi-day
partial recovery. Consumers reading CANONICAL would see the
174-country list but find many backing per-country keys missing —
contradicting the inline-comment claim that they'd see 'the prior
174-country list with their existing data.'

Fix mirrors the COVERAGE GATE / DEGRADATION GUARD failure paths:

  await extendExistingTtl([CANONICAL_KEY, META_KEY, ...prevCountryKeys], TTL).catch(...)

The keys we DO write in this run get fresh SET ... EX TTL (in the
`commands` pipeline below), so this only affects un-refreshed
entries from the prior list.

Test updated to assert prevCountryKeys is in the extend list.

99/99 portwatch tests pass; typecheck clean.