[Bug] Static fileIoExecutor causes thread leak and StrictMode violations

Dieses Issue hat noch niemand übernommen.

Description
The BlockCanary class initializes a private static final Executor named fileIoExecutor for handling log zipping and writing. However, this executor is never shut down, even when BlockCanary.stop() is invoked.

Root Cause
1. Static Resource: The executor is defined as private static final at line 133.

2. Missing Lifecycle Management: There is no mechanism to terminate the fileIoExecutor. The stop() method (Line 103) only stops the CPU and Stack samplers but leaves the IO thread pool active.

3. Process-Level Scope: In Android, this static thread persists as long as the application process is alive, which is broader than the lifecycle of the monitoring session.

Impact
1. Thread Leak: The thread named "File-IO" persists indefinitely, leaking resources.

2. StrictMode Violations: This causes StrictMode thread leak warnings (e.g., Detecting explicit GC) during integration testing or when the app attempts to exit cleanly.

Relevant Code
File: com/github/moduth/blockcanary/BlockCanary.java
// Line 133
private static final Executor fileIoExecutor = newSingleThreadExecutor("File-IO");

// Line 103: stop() does not handle the executor
public void stop() {
if (mMonitorStarted) {
// ...
mBlockCanaryCore.stackSampler.stop();
mBlockCanaryCore.cpuSampler.stop();
// fileIoExecutor is left running
}
}

Suggested Fix
Modify the lifecycle of fileIoExecutor so it can be shut down inside the stop() method, or provide an explicit release() API to terminate the underlying thread pool.

Beginnen Sie in com/github/moduth/blockcanary/BlockCanary.java mit der Untersuchung der statischen Initialisierung von fileIoExecutor und des stop()-Lebenszyklus. Testen Sie den stop-Pfad während des Integrationstests und verifizieren Sie, dass der File-IO-Thread ohne StrictMode-Warnungen wegen Thread-Leaks beendet wird.

Vom Indexierungsmodell aus dem Issue-Text verfasst.