FR: optionally auto-generate a `bazel test` target for apko lock staleness

Summary

apko already fails the build when a lock file is stale relative to its config: it records the config checksum in the lock and errors with checksum in the lock file '...' does not match the original config '...' (maybe regenerate the lock file) (this resolved #69). That works well.

It would be a useful DX addition for apko_lock (and/or apko.translate_lock) to optionally auto-generate a companion bazel test target that runs this staleness check as a test, instead of the drift only surfacing during a build.

Motivation

• bazel test //... as the single freshness gate. Many repos gate "is everything in sync?" on bazel test //.... Today, catching apko lock drift requires actually building an apko_image (which can be expensive, and isn't necessarily in the default build set on every platform/CI lane). A lightweight generated test would let bazel test //... assert lock freshness without building images.
• Convention parity with other lockfile rules. rules_python's compile_pip_requirements emits a <name>.test that fails when the requirements lock is out of date; comparable patterns exist in other rulesets. A generated apko_lock test target would match that well-established expectation.
• Clear, actionable signal. A test named after the lock makes the remedy ("run bazel run //...:<lock> to regenerate") obvious in test output, rather than surfacing as a build-action error.

Proposal sketch

Have apko_lock (and/or translate_lock) optionally emit a <name>_test — e.g. via a generate_test attribute, or a small standalone apko_lock_test rule — that:

• runs apko's existing config-vs-lock checksum validation (no network re-resolve required), and
• fails with a message pointing at the regenerate command.

Workaround

Today the build-time check can be reached under bazel test by ensuring some apko_image is transitively built by a test (e.g. a container_structure_test on the image). A first-class generated test target would be cleaner and cheaper.

Start with the apko_lock and apko.translate_lock entry points and trace the existing config-versus-lock checksum validation. Compare the proposed generated target with the rules_python compile_pip_requirements pattern and the bazel test //... workflow. Done means an optional companion test runs without network re-resolution and reports the regenerate command when the lock is stale.