Fix recurring Req.TransportError in CallHomeReporter

## Problem

All 8 production Electric Cloud instances produce recurring `Req.TransportError: socket closed` errors from `CallHomeReporter.report_home/2`. ~900 errors/day, ~10,200 in the last 7 days. Sentry issue ELECTRIC-5CH has been firing continuously since 2025-12-22 (18,641 total occurrences).

## Root cause

`report_home/2` uses `Req.post!` which defaults to HTTP/2 via ALPN. Finch's HTTP/2 pool holds a single long-lived connection per `{scheme, host, port}` and keeps it open after the request completes. Since CallHomeReporter only fires every 30 minutes, the pooled connection sits idle until the proxy/CDN in front of `checkpoint.electric-sql.com` closes it.

On the next report, Finch discovers the dead connection only when it tries to write to the socket → `Req.TransportError: socket closed`. Retries (1s, 2s, 4s) go through the same pool which may still be reconnecting, so all attempts fail. `Req.post!` raises, crashing the Task, producing the Sentry alert.

Each stack has its own CallHomeReporter and its own connection pool — there's no connection sharing between stacks. Connection pooling provides zero benefit for a 30-minute interval reporter.

### Secondary issue: stats always cleared regardless of HTTP success

`report_home/2` starts a `Task.async` and immediately returns `:ok`. The GenServer clears stats before the async HTTP request completes. If the request fails, the telemetry stats for that 30-minute period are lost silently.

## Proposed fix

In `packages/electric-telemetry/lib/electric/telemetry/call_home_reporter.ex`:

1. **Force HTTP/1.1 + close connections after each request**: Replace `Req.post!` with `Req.post` passing `connect_options: [protocols: [:http1]]` and `headers: [{"connection", "close"}]`. The `Connection: close` header causes Mint to mark the connection as non-reusable, so Finch discards it after the response. No stale connections ever sit in the pool.

2. **Make the call synchronous**: Remove `Task.async`, call `Req.post` directly in `report_home/2`. The GenServer does nothing between 30-minute cycles so blocking is fine. HTTP/1.1 NimblePool operates synchronously — no async pool messages to worry about.

3. **Return success/failure**: `report_home/2` returns `:ok` or `{:error, reason}`. The GenServer only clears stats on success. Failures are logged as warnings.

4. **Remove catch-all handle_info clauses**: The three clauses that swallowed Task.async messages are no longer needed.

## Impact

- Eliminates ~900 error logs and Sentry alerts per day
- Telemetry data is no longer silently lost on HTTP failures
- No functional impact — only affects the telemetry call-home path