refactor(cli): consolidate JFR capture loop into JfrCaptureSession

[rlaope]

Summary

Four CLI commands — gcwhy, gcscore, gcprofile, zgc — each carried their own ~50-line copy of the same JFR capture lifecycle: tempfile → JFR.start → sleep → JFR.dump → JFR.stop → file-empty check → finally delete tempfile. Subtle drift had crept in:

• gcprofile passed duration= to JFR.start, which races the explicit dump and can yield an empty file. gcwhy already documented this pitfall but the others didn't avoid it.
• zgc had a unique pre-stop + retry-on-start-fail wrapper.

This PR moves the lifecycle behind JfrCaptureSession, returning an AutoCloseable Capture so try-with-resources handles tempfile cleanup. Failures surface as the new checked JfrCaptureFailed; callers translate that into their own exit-code convention (gcwhy/gcscore/gcprofile keep return-on-fail, zgc keeps CommandExitException(2)).

• New: argus-cli/.../jfr/JfrCaptureSession.java (~111 LOC) and JfrCaptureFailed.java (checked exception)
• 4 commands migrated; net −47 lines while adding test coverage
• Tests: JfrCaptureSessionTest covers the unreachable-pid failure path (no leftover temp files) and the Capture#close deletion contract

Side effects

• gcprofile no longer passes duration= to JFR.start. This fixes a latent race where the JVM auto-stops the recording before the explicit dump.
• zgc drops its retry-once-on-start-fail loop. The helper does an unconditional pre-stop of any leftover recording with the same name, which is the case the retry was guarding against.

Test plan

• :argus-cli:test passes (incl. new JfrCaptureSessionTest)
• Full ./gradlew build -x integrationTest passes
• Smoke against a live JVM: argus gcwhy <pid> --duration=10 --format=json produces non-empty JSON
• Smoke: argus zgc <pid> --duration=10 for a ZGC JVM still produces a verdict
• Smoke: argus gcprofile <pid> --duration=10 produces an allocation profile