fix(security): isolate plugin parser subprocess network

[anshul23102]

Split out of #1700 per review feedback -- this PR is scoped to issue #1620 only.

Problem

Plugin parsers previously inherited the parent's full network stack. A malicious parser.py could exfiltrate scan findings to an attacker-controlled server over a plain socket, with no control in place.

Fix

On Linux with unprivileged user namespaces, spawn parser subprocesses in a fresh network namespace with unshare --user --net. The child has no network interfaces configured except a loopback that is down by default, so it cannot reach any host. Parsers only transform text already captured from the scanner (never network-bound); they have zero legitimate need for network access.

Unshare capability is probed once at startup via _unshare_net_supported(), which checks platform, binary availability, and runtime support. On non-Linux hosts or if the capability check fails for any reason (restrictive container runtime, disabled user namespaces, etc.), we warn once and fail open, spawning without isolation, rather than refusing all plugins. The broader threat model is documented in docs/plugins/plugin-security-checklist.md.

Testing

• testing/backend/integration/test_parser_network_isolation.py: 4 tests covering capability probe, argv construction with/without isolation, and successful parser execution under isolation -- all passing
• ruff check backend/secuscan/parser_sandbox.py -- all checks passed

Fixes #1620