[P1 validation/coverage] Split analyzeRecentOnCpu below JaCoCo JVM method limit

[bhelm]

Summary

After #101 moves backfillWorkoutFromDetectedBout to its correct small owner, the repository-wide Android coverage lane still cannot produce a clean full JaCoCo XML. On current upstream main (ec200630f2d68e9182d510a9f29f1fd85dc5eb3d), IntelligenceEngine.analyzeRecentOnCpu has a legal 56,072-byte JVM Code body, but JaCoCo 0.8.12 expands it to 66,375 bytes. That exceeds the JVM's 65,535-byte per-method limit, so JaCoCo rejects the entire IntelligenceEngine transform.

This is a P1 validation/coverage blocker, not a demonstrated runtime defect. Normal Product bytecode compiles and the Product suites execute successfully; the failure is introduced only by offline/on-the-fly probe insertion. Nevertheless, #101 cannot honestly close the full-suite no-instrumentation-error acceptance lane until this separate blocker is fixed.

Exact full-suite evidence

The affected JUnit XML records the complete causal chain:

java.lang.instrument.IllegalClassFormatException:
  Error while instrumenting com/noop/analytics/IntelligenceEngine with JaCoCo 0.8.12
Caused by: java.io.IOException:
  Error while instrumenting com/noop/analytics/IntelligenceEngine with JaCoCo 0.8.12
Caused by: org.objectweb.asm.MethodTooLargeException:
  Method too large: com/noop/analytics/IntelligenceEngine.analyzeRecentOnCpu (...)

The JVM then runs the original uninstrumented class. Therefore tests may remain green while the XML reports every method in that owner as missed. This is a class-transform failure, not evidence that analyzeRecentOnCpu or its sibling helpers were unexecuted.

Measured from a fresh current-main compile:

artifact	result
original analyzeRecentOnCpu Code	56,072 bytes
attempted JaCoCo 0.8.12 Code	66,375 bytes
JVM method ceiling	65,535 bytes
over ceiling	840 bytes
runtime Product defect reproduced	no
full clean JaCoCo XML possible	no

The combined harness capture independently saw the same failure at its product union: original 55,897-byte Code, attempted instrumented size 66,113 bytes. The boundary is therefore stable across both the live upstream build and the combined validation build.

Dependency on #101

#101 removes the exact workout-backfill helper from this oversized owner, which is the correct owner/parity fix for that helper. It deliberately does not refactor analyzeRecentOnCpu. Once #101 lands, exact backfill coverage can be collected from WorkoutDetector, but the full Android XML still contains this independent MethodTooLargeException unless the giant method is split.

This issue is therefore a separate dependency for #101's repository-wide clean-coverage gate, not a reason to mix the owner move and the analytics refactor into one candidate.

Acceptance — no waiver

• Extract one or more cohesive, private helpers from analyzeRecentOnCpu while preserving all repository-read/write order, inputs, outputs, callbacks, logs, exceptions, cancellation, and dispatcher/context behavior.
• Do not introduce parallelism, a new coroutine scope, a context switch, data copies that alter ordering, or a test-only/alternate implementation.
• Keep analyzeRecentOnCpu as the Product orchestration entry point; do not merely move the entire oversized body unchanged to another oversized method or class.
• Compile from a fresh current-upstream worktree and offline-instrument the resulting IntelligenceEngine.class with the same JaCoCo version used by the suite.
• Require every method in the class to instrument successfully. In particular, keep instrumented analyzeRecentOnCpu at or below 61–62 KB (at least about 4 KB below the JVM ceiling), with every extracted helper also comfortably below the ceiling.
• Add behavior/order regression coverage where practical plus a bytecode/instrumentation guard that fails before a future growth regression reaches the hard JVM limit.
• Run affected static/JVM tests and prove the full JUnit XML contains no MethodTooLargeException, IllegalClassFormatException, or JaCoCo instrumentation error.
• No exclusion, JaCoCo filter, annotation, exemption, forwarding copy, disabled probe, relaxed exact-method gate, or coverage waiver is acceptable.
• Keep the [P1 validation/coverage] Kotlin workout backfill owner makes JaCoCo drop exact coverage #101 owner move out of this candidate; integrate the two only in the combined validation branch after both candidates are independently proven.

Duplicate audit

Open and closed issues/PRs in bhelm/noop were searched for JaCoCo, MethodTooLarge, analyzeRecentOnCpu, IntelligenceEngine, and coverage. #101 is related but explicitly scopes the owner move and excludes this refactor; no exact duplicate was found.