ENG-8819 fix(network-ops): collect cracked passwords on time-boxed/partial hashcat and john runs

[thomasqbrady]

Summary

hashcat and john_the_ripper in network-ops/tools/cracking.py recover passwords into a potfile as they run and return them via a second --show step. But the crack step runs through the platform execute() helper, which raises on any non-zero exit — so on the normal time-boxed path (hashcat exits non-zero when the keyspace is exhausted or the --runtime box fires) the function aborted before --show ever ran, and every password hashcat had actually recovered was discarded while the operator saw a command failure.

This classifies the crack step's outcome instead of treating all non-zero exits as failure.

Changes

• hashcat: tolerate the exit codes that mean "ran, then stopped" — 1 (exhausted), 2/3 (aborted), 4 (halted by --runtime) — plus a timeout kill, then always collect results via --show. A missing compute backend keeps its actionable "use john_the_ripper" message. Any other failure (255, negative, or an error with no parseable exit code) is re-raised, so an empty --show result can never be mistaken for "nothing cracked".
• john: tolerate the run timeout (its only time box) and collect via --show; a non-zero john exit is a genuine failure and surfaces.
• Tests for both tools covering exhausted/aborted/runtime/timeout recovery, and the genuine-failure-surfaces paths (255, unparseable error, john non-zero).
• network-ops bumped to 2.1.9.

Notes

• The tolerated exit code is read from execute()'s failure text; if that text ever lacks a parseable code the error is treated as genuine and re-raised (fails toward surfacing, not swallowing).
• Exit codes were confirmed live against kalilinux/kali-rolling:latest (the sandbox base image): exhausted 1, --runtime 4, malformed hash 255, --show 0. The ticket's assumption of 2 for --runtime is actually 4 on current hashcat — hence tolerating the whole 1–4 "ran then stopped" range rather than pinning one code against an unpinned rolling image.