fix(parser-sandbox): drop PYTHONPATH/HOME and run parser child unprivileged

[Subramaniyajothi6]

Summary

Closes #1804.

parser_sandbox.py runs untrusted third-party parser.py code in a subprocess, but
_sanitised_env() kept PYTHONPATH and HOME in the child environment. An inherited
PYTHONPATH pointing at an attacker-controlled directory let the "sandboxed" parser
import arbitrary modules, and HOME was an equivalent vector via the per-user site
directory (~/.local/lib/pythonX.Y/site-packages). There was also no privilege drop, so
a backend running as root executed untrusted parser code as root.

Changes

• Lock down the child's import path in _sanitised_env():
  • Stop inheriting PYTHONPATH (direct sys.path injection) and HOME (user-site
    injection).
  • Set PYTHONNOUSERSITE=1 so ~/.local site-packages is ignored even if HOME leaks
    in via another route.
  • Set PYTHONSAFEPATH=1 (3.11+) so the process working directory — which python -c
    otherwise prepends to sys.path — cannot be used to smuggle in modules.
  • Installed dependencies are unaffected: the interpreter's own site-packages is on
    sys.path regardless of PYTHONPATH.
• Drop privileges for the parser child via a new _privilege_drop_kwargs(): when the
  backend runs as root (os.geteuid() == 0, POSIX only) the child is executed as the
  nobody account (falling back to uid/gid 65534) using subprocess's
  user/group/extra_groups parameters. It's a no-op when the backend is already
  unprivileged or on Windows.
• Apply the same privilege drop to the existing unshare --user --net capability probe
  (issue Security: plugin subprocess runs with no outbound network isolation #1620) so a host where root can create user namespaces but nobody cannot is
  detected at probe time rather than failing mid-parse.

Tests

• Flipped the two helper tests that asserted PYTHONPATH/HOME are retained (they
  encoded the vulnerable behaviour) to assert they're dropped; added coverage for the
  two new hardening flags and for _privilege_drop_kwargs() (no-op off-root / non-posix,
  targets nobody, and the 65534 fallback — using an injected fake pwd module so it
  runs on non-POSIX CI too).
• Added an end-to-end regression test that plants an evilmod on PYTHONPATH and
  confirms the sandboxed parser can no longer import it.

pytest testing/backend/unit/test_parser_sandbox.py testing/backend/unit/test_parser_sandbox_helpers.py → 43 passed. Adjacent sandbox suites pass; ruff check clean. No plugin metadata touched.

Notes

• Fail-closed: if a privilege drop is intended (root) but the syscall is denied,
  subprocess raises rather than silently running the parser as root.
• No default guard is weakened — this only tightens the parser sandbox.

@utksh1 please review this pr

[utksh1]

Dropping to nobody can make the parser source unreadable when the backend runs as root and the parser file or its parent directory is root-private. The current tests only inspect kwargs, not an actual root-owned parser execution. Please prove the root execution path can read and run a parser safely (or stage the parser in a read-only accessible location) and add a focused regression test.