Slack bot: expose a readiness/health endpoint for Socket Mode connection state

Context

Raised during review of stacklok/infra#5583/#5585 (deploying the Slack bot into staging2, h/t Samuele Verzi): the bot's Kubernetes Deployment has no readiness or liveness probe, because the bot exposes no HTTP listener at all — it's Slack Bolt in Socket Mode (an outbound-only WebSocket) plus outbound gRPC to mecak8s, no inbound port.

Without a probe, Kubernetes marks a new pod Ready the instant the container process starts — before app.start() has actually established the Socket Mode connection to Slack. On a rollout, the old (working) pod can be terminated in favor of a replacement that isn't actually functional yet. With only 1 replica, this is a real gap, not just hygiene.

Immediate mitigation applied in infra#5585: strategy.type: Recreate instead of the RollingUpdate default — honest about the single-replica limitation (a brief window with zero pods during a rollout) rather than implying a continuity guarantee the deployment can't actually back up without a real signal.

What's needed

Add a minimal HTTP health-check server to the bot (sdk/typescript/examples/slack-bot), listening on a small dedicated port, that:

• Returns non-ready (503 or similar) until app.start() resolves and Socket Mode is confirmed connected.
• Flips to ready once the "mecatl Slack bot is running (Socket Mode)" log line's condition is true.
• Optionally: a liveness signal that can detect a wedged/disconnected process (Bolt's Socket Mode client should have reconnect/error events to hook).

Once this exists, the infra-side Deployment should get a real readinessProbe/livenessProbe and can revert strategy.type back to RollingUpdate.

Not urgent, not blocking anything currently deployed — tracked so it doesn't quietly disappear, same as #1085 (hardened base image).