fix(extractor): make TikaExtractor System.out muting thread-safe and avoid double temp file

[marevol]

Summary

• Replace per-call System.setOut/System.setErr swap with a ref-counted mute/unmute under a class lock so concurrent extractions cannot race and leave the JVM streams permanently redirected.
• When the deferred output spills to disk, read it back via TikaInputStream.get(Path) instead of letting Tika spool the bytes a second time inside TikaDetectParser.parse.
• Add setMuteSystemStreams(boolean) (default true) for users who want the original output preserved (e.g., debugging).
• Tighten error messages to key=value format and stop double-wrapping the bomb-detection ExtractException.

Why

Some Tika-bundled parsers print to System.out/System.err during parsing. The original mute logic is intentional, but the un-synchronized swap was unsafe under concurrent crawls — once two threads raced through the swap, the original streams could be lost. Also, on large inputs the DeferredFileOutputStream spilled to disk and Tika immediately re-spooled into a second temp file (apache-tika-*) on top of the existing tikaExtractor-* staging file.

The new implementation only synchronizes the swap itself, not the extraction work, so concurrent extractions are not serialized. Wrapping the staging file with TikaInputStream.get(Path) lets Tika's internal TikaInputStream.get(stream, tmp, metadata) short-circuit (since the input is already a TikaInputStream), reusing the existing file path.

Tests

• Concurrent extraction (16 threads x 8 iterations) does not corrupt System.out/System.err.
• Streams restored on exception (both null-input fast path and broken-stream during-mute path).
• DFOS-on-disk path no longer creates a second apache-tika-* temp file.
• DFOS-in-memory path creates no temp file at all.
• setMuteSystemStreams(false) leaves the streams alone throughout extraction.

Test plan

• CI green
• Manual review of mute/unmute ref-count
• Run test suite under high concurrency locally