fix(jellyfin): decide container readiness by healthcheck, not docker logs --since

[bilbospocketses]

Reported as "the database date update keeps failing at starting the docker container." It was not failing to start the container.

What was actually happening

From your own operation log — every real step succeeded:

14:03:33 OK    Container 6a1bca888abd stopped
14:03:34 OK    Backup saved: jellyfin_20260826_190333.db
14:03:34 OK    SQL update applied: DateCreated = PremiereDate
14:03:34 STEP  Starting Docker container
14:03:35 STEP  Waiting for 'Startup complete' in container logs
14:04:37 FAIL  Jellyfin did not report 'Startup complete' within 60s

The container started and Jellyfin came back healthy. Only the readiness verification failed — and because one step covered both the start and the wait, a readiness timeout was indistinguishable from docker start refusing.

Root cause

Readiness polled docker logs --since <timestamp> for Jellyfin's Startup complete line. That primitive does not work on a long-lived container. Measured on the affected container (467k lines, June 6th onward):

--since 2026-06-01T00:00:00Z  ->  467,127 lines
--since 2026-08-01T00:00:00Z  ->   32,059 lines
--since 2026-08-26T19:00:00Z  ->        0 lines   <- the burst is right there
--since 2026-08-26T19:04:00Z  ->        0 lines
--tail 5                      ->        5 lines

Jellyfin logged Main: Startup complete 0:00:13.53 14 seconds after start. The check simply could not see it.

Nothing in this codebase changed. The same code succeeded on 2026-06-30 per its own operation log. The container's log grew and --since stopped behaving.

Fix

Two independent signals, whichever lands first:

1. The container's own healthcheck — authoritative when the image defines one, and the Jellyfin image does (curl $HEALTHCHECK_URL, 30s interval).
2. Fallback: docker logs -t --tail 200, comparing docker's own RFC3339 timestamps against the container's start time.

That timestamp comparison is what --since was really providing: a long-lived log holds the marker from every previous start, and matching one of those would report ready while the server is still booting — worse than the bug being fixed. There is a test pinning exactly that case, and another pinning --since out so it cannot creep back.

Budget goes 60s → 120s, because a healthcheck only flips on its first passing probe. The marker match stays case-sensitive deliberately: the same log carries Core startup complete and plugin lines like MediaBar Startup Completed, neither of which means the server is up.

Also drops an unconditional 3s sleep before the first probe — the readiness tests went from 15s to 94ms.

Not changed, deliberately

JellyfinService still shells docker as a bare PATH-resolved name. Docker is registered as an External dependency here, and this is an accepted standing exception to Local-Dependencies-Only.

Verification

• 726 tests green in Release.
• Both signals mutation-checked: removing the timestamp guard fails the stale-marker test; ignoring the healthcheck fails the healthy test.