Feature: Add a public diagnostic holder #372

Description, motivation and use case
Diagnostics are stored by ElementHolder, but the public API is limited to dedicated methods such as get_betatron_tune_monitor(name). The original holder proposal calls for a diagnostic namespace that supports both a default monitor and named monitors.

This gives application code a stable, discoverable entry point for diagnostics without relying on private registry methods.

Proposed solution
Add a public diagnostic property returning a diagnostic holder:

• diagnostic.get(name) returns the named diagnostic.
• diagnostic.get() returns all available diagnostics as an untyped collection.
• diagnostic.betatron_tune resolves the DEFAULT_BETATRON_TUNE_MONITOR entry and validates that it is a BetatronTuneMonitor.

For an absent default or an incompatible configured type, raise a clear PyAMLException. Preserve get_betatron_tune_monitor(name) as a backward-compatible API.

Describe alternatives you've considered
Exposing _DIAG directly would make discovery easy but would expose mutable holder internals. Adding more direct convenience methods to ElementHolder would continue to grow its public surface instead of grouping related APIs.

Example

default_tune_monitor = sr.live.diagnostic.betatron_tune
measured_tune = default_tune_monitor.tune.get()

spare_tune_monitor = sr.live.diagnostic.get("SPARE_BETATRON_TUNE_MONITOR")
all_diagnostics = sr.live.diagnostic.get()

Additional context
Parent issue: ElementHolder API refurbishment #199.

The base holder already stores diagnostics in its internal registry and supplies private discovery helpers for YellowPages. This issue adds the missing public diagnostic façade.

Checklist

• I've assigned this issue to a project
• I've @-mentioned relevant people