Fix container startup fragility under wrapped runtime execution

Summary

Fix container startup fragility by removing runtime Python virtual environment activation and switching to an exec-form Python ENTRYPOINT and HEALTHCHECK. Runtime Python resolution is now handled deterministically via PATH, making startup reliable under CI/CD runners, container wrappers, and orchestration layers.

This:

• aligns the image with Docker and OCI best practices and ensures deterministic startup across environments.
• allows Tailscale to be enabled on Unraid.

Why

The previous container startup relied on shell-based runtime logic:

• /bin/bash -c
• . /venv/bin/activate

This pattern is fragile because containers are not guaranteed to be started directly by Docker in all environments. CI/CD systems, process supervisors, and orchestration layers may wrap or re-exec the container under /bin/sh, change PID 1 behavior, or alter signal handling.

Under these conditions, shell-dependent ENTRYPOINT logic can fail even though the image builds successfully. This PR removes that failure mode by:

• Treating the Python virtual environment as a build-time concern
• Selecting the runtime interpreter via PATH
• Using exec-form commands exclusively at runtime

Scope

• Backend API
• Setup / install flow
• Config / schema
• Service orchestration
• Embedded UI / proxying
• Docs
• Other

Testing

What was tested

Testing focused on container runtime behavior rather than application logic:

• Built the image from a clean environment using the updated Dockerfile
• Executed the container using exec-form ENTRYPOINT only
• Verified:
  • The application starts successfully
  • The Python interpreter resolves to /venv/bin/python
  • The HEALTHCHECK executes and reports healthy
  • SIGTERM/SIGINT signals propagate correctly to the Python process

The image was exercised under both direct Docker execution and wrapped execution (representative of CI/CD and supervised runtimes). Startup behavior was consistent in all cases.

Why automated tests were not added

This change affects container startup semantics, not application logic. The failure mode occurs before application code runs and depends on how the container process is launched or wrapped.

Unit or integration tests would not meaningfully validate this behavior. Manual runtime verification is the appropriate validation method for this class of change.

• Not run (explain below)
• Manual testing completed
• Automated tests updated or added

Related Issues

• Startup failures caused by shell-dependent ENTRYPOINT logic under wrapped execution
• General container fragility when relying on runtime activate / source

Checklist

• PR targets dev (unless release automation or exceptional maintainer change)
• PR title follows Conventional Commits
• Changes are focused to one logical improvement
• Documentation updated where behavior changed
• No secrets or local-only artifacts committed

Notes

• Builder stages continue to use virtual environment activation at build time only; this is safe and unchanged
• No application behavior or configuration is altered beyond startup mechanics
• Improves compatibility with CI/CD runners, supervised containers, and orchestration platforms
• Follows best practices:
  • Exec-form ENTRYPOINT
  • No runtime shell dependency
  • Deterministic interpreter selection via PATH

Summary by CodeRabbit

• Chores
  • Streamlined container runtime initialization for improved startup efficiency.
  • Enhanced container health check mechanism.
  • Optimized container build process.