Hash small items inline and bound the digest thread pool

[T0k1To]

HashTask submits one task per algorithm per 1MB chunk to a shared unbounded thread pool and waits on a CountDownLatch, even when the item fits in a single chunk. For small items (the vast majority in a typical case) the executor round-trip and the latch cost more than the hashing itself, and there is no next chunk to overlap with.

Changes:

1. Items with size <= 1MB now update all digests inline in the worker thread, reusing a per-task buffer (this also avoids allocating two 1MB buffers per small item). Multi-chunk items keep the existing pipelined path: reading the next chunk still overlaps digesting the current one, and the digests of a chunk still run in parallel.
2. The shared digest pool is now bounded to the number of available processors. The unbounded cached pool could reach workers x algorithms threads (for example 24 workers x 4 algorithms = 96 digest threads competing with the 24 worker threads), oversubscribing the CPU. This matters most on machines with few cores.

Microbenchmark of the hashing stage (8 workers, MD5+SHA-1+SHA-256, CPU saturated, 3 runs):

• 32KB items: 1.13x to 1.17x faster
• 4KB items: 1.9x to 2.1x faster

Both paths produce the same digests; behavior for large items is unchanged. Pure Java, no new dependencies, no OS- or hardware-specific code, and the change reduces (not increases) thread and memory pressure on low-end machines.