Resolve file paths in key=value attack arguments

[four-random-common-words]

Ports the fix from hashtopolis/agent-python#79 to the Rust agent.

Problem

Hashcat's PCFG support (-a 4) passes a hint file as a key=value argument, e.g. hintfile=mylist. Both cracker backends resolved file tokens by joining the whole token onto the files directory and testing is_file(). A key=value token never matched a real file, so the path was never substituted and the run failed. The Python agent had the same bug before #79.

Fix

• New shared resolve_file_token helper in src/backend/paths.rs. A bare token naming a file still resolves to its absolute path. A key=value token whose value names a file now resolves to key=<absolute path>, stripping matching surrounding quotes from the value first.
• The hashcat backend (argv.rs) and the generic backend (mod.rs, covering both crack and keyspace paths) now call the shared helper, removing the duplicated lookup logic.

Because the Rust agent builds a real argv vector instead of a quoted shell string, no re-quoting is needed. A bare filename containing = is matched as a whole file first, before any key=value split.

Tests

Added coverage in all three locations: the helper's unit tests (bare file, key=value, quoted value, missing file, non-file flag like --hash-type=0, empty value, bare-file-with-= precedence) plus regression tests in the hashcat and generic backends including the keyspace path. Full library suite passes and clippy is clean.