Fix agent going inactive on --increment speed benchmarks

[urbanadventurer]

Problem

An agent assigned a mask/brute-force task that uses --increment becomes
Inactive and never recovers. The server log shows the benchmark being retried
and failing over and over:

Agent 2 sent error: Speed benchmark failed!
Agent 2 sent error: Speed benchmark failed!
...

Example task (from a supertask):

-a 3 #HL# ?1 --increment --increment-min=1 --increment-max=6 -1 ?l?u?d?s

Root cause

The speed benchmark runs hashcat with --progress-only, and hashcat refuses to
combine --progress-only with --increment:

$ hashcat --progress-only -a 3 hash '?1' --increment --increment-min=1 --increment-max=6 -1 '?l?u?d?s'
Increment is not allowed in combination with --progress-only.
$ echo $?
255

So the benchmark exits non-zero for every increment task. The agent turns
that into a clientError. On the server, APIClientError.php deactivates an
agent on its first error whenever ignoreErrors == 0 (the default), so the
agent flips to isActive = 0 and can only be revived by hand. The agent loop
keeps re-requesting the task every ~10 s, reproducing the repeated log lines.

A second, smaller bug makes this hard to diagnose: in run_speed_benchmark,
output is reset to b'' immediately before the try, so on
CalledProcessError the code logs output.decode() (always empty) and never
looks at e.output, which holds hashcat's real message. The local error log is
always blank on any speed-benchmark failure.

Fix

Commit 1 — the increment benchmark failure:

1. Strip the increment flags before running --progress-only. The measured
   cracking speed is independent of the mask length / increment range, so the
   benchmark stays valid. A new strip_increment() helper in helpers.py is
   applied to the speed-benchmark command only (not to --keyspace or the
   --runtime run benchmark, which accept --increment).
2. Capture hashcat's error output — read e.output instead of the
   always-empty output, so the error log line for a genuine benchmark failure
   is no longer blank. The error sent to the server is unchanged
   ("Speed benchmark failed!"), to avoid bloating server-side AgentError
   records with multi-line hashcat output.

strip_increment() intentionally iterates the tokens directly rather than
routing them through the existing clean_list() helper (see commit 2 for why).

Commit 2 — related robustness bugs found while fixing the above (kept as a
separate commit so it can be reviewed or split off on its own):

3. clean_list() deleted from a list while iterating it (del element_list[index]
   inside for part in element_list), which skips elements and leaves real
   tokens — and empty strings — behind. On the runs of spaces in the assembled
   benchmark command this dropped the attack mask itself (e.g.
   -a 3 #HL# ?d?d?d?d?d → bare -a 3), after which hashcat falls back to its
   built-in default mask, which references ?1, and fails with
   Custom-charset 1 is undefined. Rewritten as [p for p in element_list if p].
   This also stops get_wordlist() from raising IndexError on the empty
   strings clean_list() used to leave (its part[0] check assumes none remain).
   clean_list()'s only two callers (get_wordlist, get_rules_and_hl) use the
   return value, so returning a fresh list instead of mutating in place changes
   nothing for them.
4. measure_keyspace() had the same swallowed-output bug as (2) — fixed the
   same way (e.output).
5. The PRINCE branch of run_speed_benchmark() called
   get_rules_and_hl(update_files(task['attackcmd'])) with one argument; the
   signature is (command, alias), so it raised TypeError. Pass the hashlist
   alias, matching the correct call in the preprocessor path. (PRINCE is
   deprecated; included only because it's a guaranteed crash if that path runs.)

Alternatives considered

• Skip the speed benchmark for increment tasks rather than rewrite the
  command — but the agent still needs a speed figure for chunk sizing, so
  stripping --increment and measuring the base mask is the least-disruptive fix
  (cracking speed for a mask attack is independent of mask length / the increment
  range, so the number stays valid).
• Fix it server-side by not requesting a "speed" benchmark for increment
  tasks — larger blast radius, and the agent would still mishandle a
  --progress-only+--increment command it was handed. Keeping the fix in the
  agent that builds the command is the more contained change.

Testing

• tests/test_helpers.py: 8 unit tests, all passing — strip_increment (=
  form, space-separated form, short -i, no-op cases, and a regression test
  that the mask survives runs of spaces) and clean_list (consecutive empties,
  full list untouched).
• Verified against hashcat v6.2.5 that the raw increment command errors with
  "Increment is not allowed in combination with --progress-only." (exit 255)
  and that strip_increment clears it.
• Verified end-to-end on a live 6.2.6 deployment: after the fix the agent
  benchmarks both a real increment task and a plain-digit mask task cleanly,
  cracks, and stays active — zero benchmark errors.

Notes / follow-ups (not in this PR)

• Hashcat masks (?d, ?l, …) are interpolated into the command string that is
  run with shell=True, unquoted; ? and * are shell globs, so a mask can be
  glob-expanded against files in the cracker/working directory. It rarely
  matches real filenames, but quoting masks would remove the hazard.
• --keyspace accepts --increment but reports the keyspace of only the base
  mask, so chunking can under-count for increment tasks.
• The server deactivating an agent on a single benchmark-measurement error is
  arguably too aggressive; treating measurement errors as task-level rather than
  agent-level would be a more robust server-side change, but that's out of scope
  here.

[s3inlc]

Exactly this --keyspace accepts --increment but reports the keyspace of only the base mask, so chunking can under-count for increment tasks. is the reason why --increment is not compatible with Hashtopolis (until very recent hashcat beta changes which grouped the keyspace of all increments together).
Hashcat treated the parts of the increment steps as each separate attacks (which is just looped outside each after the other), which was not allowing any way to distribute over this loop. That's why --increment needed to be used split into the separate tasks of the increment steps (see FAQ https://docs.hashtopolis.org/faq_tips/faq/#hashcat-questions).

The solution to just remove the --increment where problematic does not solve this problem as in hashcat it was meant to not work like that (i.e. benchmarking with --progress-only does only work if you have only one keyspace, it just conceptually does not work to run against multiple tasks at once). This change would just introduce additional problems in the step where the task then actually is executed, as --increment and --keyspace do not work together either.

With the commits in hashcat from last week, hashcat introduced a way that it can give a keyspace overall a whole increment command and therefore will be possible to distribute. But this then does not require a change on Hashtopolis side, as then --increment MUST stay in the command in all calls.