chore: migrate OCI image build from rules_pkg pkg_tar to aspect_rules_py py_image_layer

[shaoster]

Problem / Motivation

The OCI image build in `BUILD.bazel` uses `rules_pkg`'s `pkg_tar` for two layers:

• `app_src_tar` — Django source files
• `web_dist_tar` — Vite frontend build output

`rules_pkg`'s internal `build_tar.py` tool is invoked via `/usr/bin/env python3`, which requires a host `python3` binary. This is a non-hermetic dependency that breaks `bazel test //...` in environments without a host Python (including the devcontainer, which uses Ubuntu 24.04 with no pre-installed Python). Discovered while validating the devcontainer in #464.

The `python_layer_tar` genrule (pip deps layer) is already hermetic — it uses `$(PYTHON3)` from `@rules_python//python:current_py_toolchain`. Only the `pkg_tar` rules are affected.

Proposed Solution

Replace both `pkg_tar` targets and the `python_layer_tar` genrule with `py_image_layer` from `aspect_rules_py` (already a dependency at v1.11.5, which introduced `py_image_layer` in v1.10.0).

`py_image_layer` takes a `py_binary` and partitions its runfiles into OCI-compatible tarballs by path pattern — no host Python required, fully hermetic, and better Bazel cache behaviour than the current genrule + pkg_tar approach.

Migration steps

1. Define a `py_binary` target for the Django app server (entrypoint: `manage.py runserver` or the gunicorn/uvicorn command used in `docker-entrypoint.sh`)
2. Replace `python_layer_tar` + `app_src_tar` + `web_dist_tar` with `py_image_layer` groups (deps / src / web partitions)
3. Update `docker-entrypoint.sh` to launch via the Bazel runfiles launcher instead of bare `python manage.py`
4. Verify `bazel run //:image` and `bazel run //:load` still produce a working container
5. Confirm `bazel test //...` passes in the devcontainer without any host Python

Out of Scope

• Changing the devcontainer base image or adding host Python as a workaround (this issue IS the proper fix)
• Modifying CI/CD workflows beyond updating the image build targets