docker: give the image a healthcheck it can actually run

[m4bard]

Closes #940.

Adds a HEALTHCHECK to both Dockerfiles. 14 lines added, nothing removed, no application code touched.

HEALTHCHECK --interval=30s --timeout=5s --start-period=90s --retries=3 \
	CMD ["node", "-e", "require('http').get('http://127.0.0.1:4545/api/v1/system/ready', res => process.exit(res.statusCode === 200 ? 0 : 1)).on('error', () => process.exit(1))"]

#940 carries the reasoning. In brief, on each choice:

The command runs node rather than pulling in a package. The runtime ships no HTTP client, so a curl or wget check would mean putting one back. Dockerfile.runtime:36 records that node is kept deliberately for the Discord bot ("the bot only needs node"), so the request goes through that binary instead. It adds no package and no layer.

It asks /api/v1/system/ready rather than /. That endpoint is [AllowAnonymous], so it answers with authentication enabled, and it returns 200 or 503 off real database, migration and filesystem state. A request to / would only prove the static file middleware is mounted.

Both Dockerfiles get it. The publish workflow builds listenarr.api/Dockerfile.runtime; the root Dockerfile is the local build. Patching one and not the other would let the two disagree about what a healthy container means.

On the intervals: 30s apart with a 5s timeout is cheap for one local HTTP request. The 90s start period is the one worth explaining. Failures inside that window do not count against the retry budget, and a first boot with migrations to run can take a while, so a generous window keeps a slow start from being reported as unhealthy.

If you build this with podman

Podman's default OCI build format drops HEALTHCHECK. It does warn, but the warning is easy to miss, so a locally built image looks as though this change did nothing. Build with --format docker and the instruction survives.

The published image is unaffected. CI builds through buildx, and the config blob of another buildx-built image using the same OCI media types from the same registry carries a populated Healthcheck.

What was checked

By running, against stock ghcr.io/listenarrs/listenarr:canary:

• curl, wget, nc and busybox are all absent, and the naive curl healthcheck exits 127.
• Both exit branches of the new command: 200 gives 0, 503 gives 1, connection refused gives 1.
• The command succeeding against the real running application.
• The instruction landing in image metadata after a build.
• A container transitioning to Status=healthy with FailingStreak=0.

I have not run this in production. The evidence above comes from a test container.

Worked through with Claude Code at my direction. The image contents and both exit branches were checked by running them against the published image, and I watched a container reach healthy before opening this. I reviewed this before posting.