Mitra availability: read paths respect require_mitra_ping=false

When the operator sets require_mitra_ping=false, the auto-offline sweep
early-returns (by design — "don't gate online status on heartbeat
freshness"). The three Valkey read paths still gated on heartbeat
freshness anyway, which trapped the system: sweep won't remove the
mitra from mitras:online, but readers reject them as stale. The customer
CTA stayed permanently disabled with no recovery.

Fix all three to skip the heartbeat-freshness check when require_ping
is off, matching the sweep's contract:
- computeAvailabilityFromValkey (customer beacon)
- isMitraReachable (extension service)
- findAvailableMitrasFromValkey (pairing candidate finder)

The Postgres fallbacks already did the right thing (is_online only,
no heartbeat compare); this aligns the Valkey hot path.

Also: PATCH /internal/config/mitra-ping now publishes config:invalidate
for require_mitra_ping and mitra_stale_after_seconds, and the subscriber
in mitra-status.service was widened to listen for both. Flipping the
toggle in CC now busts the 10s availability snapshot immediately instead
of waiting out the TTL.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

backend/src/routes/internal/config.routes.js

@@ -190,6 +190,14 @@ export const internalConfigRoutes = async (app) => {
       }
     }
     const config = await setMitraPingConfig({ require_ping, stale_after_seconds })
+    // Bust the customer availability cache on any instance — subscribers in
+    // mitra-status.service.js listen for these keys and call invalidate.
+    if (require_ping !== undefined) {
+      await publishConfigInvalidate('require_mitra_ping')
+    }
+    if (stale_after_seconds !== undefined) {
+      await publishConfigInvalidate('mitra_stale_after_seconds')
+    }
     return reply.send({ success: true, data: config })
   })