1.1.1: Anchor parse_apk to the system temp dir (CodeQL py/path-injection #4)

CodeQL flagged ``parse_apk(path)`` as reachable from user-controlled
data via the upload flow:

  UploadFile -> save_upload_to_temp -> tempfile.NamedTemporaryFile
  -> Path(tmp.name) -> parse_apk(path) -> Path(path).exists()

In practice the path comes from ``tempfile.NamedTemporaryFile`` (or
the rescan service's ``_download_apk`` which uses the same primitive)
and an attacker controls none of it — the path is an OS-allocated
random name under the system temp dir. But CodeQL's tracker can't see
that, and we'd be exposed if a future caller ever passed a
caller-controlled path by mistake.

Fix: validate up-front in ``parse_apk`` that the resolved path lives
under ``tempfile.gettempdir()`` and points at a regular file. Two
wins:

* Defence-in-depth — a stray future caller can't aim androguard at
  ``/etc/passwd`` (or any non-APK file) by accident. We fail loudly
  with ``ApkParseError`` before the FS open.

* The explicit ``Path.resolve(strict=True).relative_to(tmpdir)``
  check is the sanitiser shape CodeQL's ``py/path-injection`` rule
  recognises, so the flow no longer trips the analyser.

Smoke-tested in the running container: missing paths and out-of-tmp
paths both raise ``ApkParseError`` with the new messages; a tempfile
fed garbage bytes still reaches androguard (validation passed, parse
fails downstream — expected).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>