Qodana JVM resource-leak inspection: baseline legacy findings or gate on severity counts?

Assuming a recent JetBrains JVM linter image, the goal is to use its resource-leak inspections for unclosed Closeable values as a CI guard, so a leak-prone pattern cannot quietly return after a fix. Static analysis inspects source, not runtime behavior, so it complements rather than replaces profiler or heap-dump evidence.

Two constraints shape the setup:

• Static findings are heuristic: they cover closeables left open on some execution path, not heap retention, off-heap or native leaks, listeners, or caches.
• Inspection names, IDs, and default severities follow the underlying IntelliJ engine and can shift between linter releases; comparisons are only reliable with the linter version pinned, and the exact inspection ID is version-specific, so it should be confirmed against the pinned release's report.

The open decision is the gating policy. Qodana's quality gate supports a baseline, where pre-existing findings are recorded and only new problems count, and absolute severity thresholds via failThreshold in qodana.yaml. The policies define a verified fix differently: a baseline ignores legacy findings indefinitely, while an absolute count forces cleanup but adds churn.

Should the gate fail only on new resource-leak findings above a chosen severity, with current findings baselined? Or should an absolute threshold apply, and how would pre-existing findings be handled? Which pinned linter version and inspection ID should the policy reference so results stay comparable?