worker: PORT/HEALTH_PORT precedence is inverted relative to every sibling service

Found during the review of #180. Not changed there — altering port precedence on a hotfix risked the live deploy.

apps/worker/src/index.ts resolves process.env.PORT ?? process.env.HEALTH_PORT ?? '3003', preferring PORT. Every other health-serving app reads HEALTH_PORT only (apps/discord-bot, apps/slack-bot, apps/teams-bot, apps/linear-sync), reserving PORT for a separate listener. The worker is the outlier, and docs/deployment.md already documents the asymmetry as known.

Three concrete problems:

1. Whenever the platform injects PORT, the app binds it while ENV HEALTH_PORT=3005 and EXPOSE 3005 say otherwise. #180 made the Dockerfile HEALTHCHECK follow the same precedence as a stopgap, but the underlying disagreement remains.
2. PORT="" (a cleared platform variable) yields parseInt('') → NaN, and listen(NaN) throws ERR_SOCKET_BAD_PORT synchronously at module scope — the process dies before binding, producing the same opaque "replicas never became healthy" signal as the original incident.
3. The code's 3003 fallback disagrees with the Dockerfile's 3005 and collides with teams-bot's port.

Also worth fixing alongside: healthServer has no 'error' listener, so EADDRINUSE/EACCES is an uncaught exception with a bare stack trace.

Start in apps/worker/src/index.ts, then compare port handling with apps/discord-bot, apps/slack-bot, apps/teams-bot, and apps/linear-sync. Review the Dockerfile and docs/deployment.md for the documented port contract. Done means the worker's configured health port, fallback, Docker health check, and server error behavior no longer disagree or fail opaquely.