Support multi-chunk encrypted uploads in web interface

[sergarsilla]

Proposed Changes

Encrypted file uploads in the web interface only processed the first chunk.
handleUpload used a static int chunck_no counter and returned 404 "file is too big" on any second chunk, so files larger than one AsyncWebServer chunk
(~1.4 KB) could never be uploaded encrypted.

The root cause was that encryption was done with encryptString(), which writes
a complete self-contained file (header + a single Data: line) and restarts the
position-based XOR keystream at offset 0. Calling it per chunk would emit multiple
headers/Data: lines and reset the keystream, which the reader
(readDecryptedFile) cannot decrypt — hence the hard single-chunk limit.

This PR encrypts uploads incrementally instead:

• encryptFileHeader() writes the encrypted-file header once (on the first
  chunk), ending with the Data: prefix.
• encryptChunkToHex() encrypts each chunk on its own and appends its hex bytes
  to that single Data: line. It uses the chunk's absolute plaintext offset
  (index, provided by AsyncWebServer) so the XOR keystream stays continuous
  across chunks — the resulting file decrypts identically to a single-shot one.
• The trailing newline that terminates the Data: line is written on the final
  chunk.

Only the encrypted path changed; the plain (non-encrypted) upload path is
untouched.

Types of Changes

Bugfix

Verification

1. Open the web interface and upload a text file larger than one chunk (a few KB
   is enough) with an encryption password set.
2. Before: the upload failed with 404 "file is too big". After: the full
   .enc file is written.
3. On the device, open the uploaded .enc file and enter the same password; it
   decrypts to the original content (readDecryptedFile).
4. Small single-chunk files still encrypt and decrypt exactly as before.

Builds clean for lilygo-t-embed-cc1101; the change is board-agnostic.

Testing

Not covered by automated tests (no harness for the web-upload path). Verified by
building the firmware and by tracing the encrypt/decrypt round-trip: the reader
parses the Data: line in fixed 3-char groups and XOR-decrypts from offset 0, so
the streamed output (fixed two-digit hex per byte, keystream keyed by absolute
offset) round-trips correctly for both single- and multi-chunk uploads.

Linked Issues

Resolves the // TODO: handle multiple chunks in
src/core/wifi/webInterface.cpp (the handleUpload encrypted path).

User-Facing Change

Web interface: encrypted file uploads now support files larger than one chunk instead of failing with "file is too big".

Further Comments

Memory-safe by design for the ESP32: the file is never buffered whole in RAM. Each
chunk allocates only a transient hex string (~3x the chunk size) that is written
and freed before the next chunk. There is no longer a hard size limit — uploads
are bounded only by free space on the target filesystem.

As a side effect the encrypted path is more robust than before: bytes are now
emitted as fixed two-digit uppercase hex (the previous String(byte, HEX) dropped
the leading zero for values < 0x10, which the fixed-width reader parses
incorrectly), and chunk data is read by exact length rather than through
String((char*)data), which stopped at the first null byte.