Allow uploading and storing cracker binaries on the server

[s3inlc]

Cracker binaries can now be stored on the server itself instead of only referencing an external download URL. Existing URL-based binaries are fully unaffected.

Upload (apiv2)

• POST /api/v2/ui/crackers accepts an alternative to downloadUrl: sourceType/sourceData with three sources:
  • import: consume an archive uploaded through the existing chunked (TUS) upload to the import directory — the path for arbitrarily large archives, no PHP request-size limits involved
  • url: the server fetches the archive itself (http/https only)
  • inline: base64 archive data for small uploads
• Only .7z archives are accepted (7z magic-byte validation); the archive filename is server-composed ({crackerType}-{version}.7z), and the downloadUrl is set automatically to the server's download endpoint — no client-supplied filenames or URLs
• New nullable filename column on CrackerBinary doubles as the local-storage flag (NULL = external URL binary, as before)

Download

• New generic endpoint GET /api/download.php/{kind}/{id} (kind registry, extensible to files/hashlists later) — authenticated with either an agent token (?token=) or an apiv2 Bearer JWT; streams with HTTP Range and ETag support
• Agents require zero changes: the downloadBinary action appends the requesting agent's token to the URL of locally hosted binaries, so the existing fetch-and-extract flow just works
• Deleting a binary (or a whole cracker type) also removes its stored archive; the downloadUrl of local binaries is server-owned and cannot be patched