Fix queue metrics visibility under restricted ACL contexts

[Flamki]

What problem does this solve?

jenkins.queue.count can report 0 for all statuses when queue metrics are collected in a restricted security context (for example anonymous context in hardened Jenkins setups). This hides queued/stuck items even though they are present in Jenkins UI/API.

This change wraps queue item reads for metric collection in ACL.SYSTEM2 so queue gauges are based on full queue visibility.

Fixes #1174.

How to test the change

1. Run ./mvnw spotless:check
2. Run ./mvnw test -Dtest=MonitoringQueueListenerTest
3. Run ./mvnw spotbugs:check

Breaking changes

None.

Additional notes

A regression test (MonitoringQueueListenerTest) verifies that:

• anonymous context sees no queue items,
• metrics collection path still sees queued items via SYSTEM ACL.

[ArpanC6]

Great fix @Flamki! Wrapping queue item reads in ACL.SYSTEM2 is exactly
the right approach for infrastructure-level metrics that must observe
the full queue regardless of the caller's security context.

A few observations:

1. ACL.SYSTEM2 pattern — Using ACL.SYSTEM2 instead of the deprecated
   ACL.SYSTEM is consistent with the rest of the codebase. The
   try-with-resources pattern for ACLContext is also the correct Jenkins idiom.

2. Test coverage — 100% line and branch coverage is excellent. The
   test elegantly proves the fix by verifying that anonymous context sees 0
   items while the metrics path sees the queued item via SYSTEM ACL.

3. @VisibleForTesting — Extracting getQueueItemsForMetrics() as a
   package-private method with @VisibleForTesting is a clean design
   choice — it makes the fix testable without exposing unnecessary API surface.

All CI checks passing including 235 tests on Linux. This looks ready
for merge!