Audit: acquisition integrity, collector correctness, and release hardening

[besendorf]

A file-by-file audit of the current main branch found the following issues:

1. The collector's /proc/<pid>/stat parser fails after the process name, leaving state, parent/session IDs, CPU counters, and priority at zero. CPU conversion is also guarded by the wrong condition, and UID/path fields are never populated.
2. Backup and bugreport ZIP entries are created before their ADB commands succeed. A failed command can therefore leave a partial entry that is included in hashes.csv.
3. On-device hashing allocates each complete file in memory across multiple workers, performs only one Read, and silently omits hash errors. Per-root collection failures are then dropped while a partial files.json is still written; deduplication is quadratic across overlapping roots.
4. Package parsing indexes unchecked fields and can panic on malformed or empty output. The old-Samsung fallback also parses installer output as a UID.
5. The fallback find parser can panic on short records and changes spaces in paths into / characters.
6. Collector deployment ignores os.CreateTemp errors, reinstalls an already-installed collector in Processes, and does not select its built amd64 asset.
7. The collector depends on github.com/opencontainers/selinux below the version fixed for GO-2025-4098.
8. Module failures do not affect the final success status or appear as structured acquisition metadata.
9. The nested collector module is built but receives no tests, vet, staticcheck, or vulnerability scan in CI.
10. Release tooling downloads mutable platform-tools archives without checksum validation and uses mutable action/tool versions.
11. An unknown interactive -module value silently produces an empty archive.

Additional lower-impact problems include indefinite retrying in non-interactive mode, stale running-state detection based only on PID existence, permissive state-file modes, and cleanup gaps on initialization failure or interruption.

The audit reproduced the process-data corruption directly and validated the repository with race tests, vet, staticcheck, coverage, cross-builds, and vulnerability scans. A follow-up PR will fix the findings in separate reviewable commits and update dependencies in both Go modules.