Fleet pane: targets are first-class, identity is (target, scheduler), and a cluster shows once with its nodes

Today the dashboard keys everything by the scheduler-name string: SchedulerState, the picker, the hub group, the history store and SchedulerResource(name). Two unrelated processes each running the default-named QuartzScheduler cannot both be fronted, and a clustered scheduler reached through several nodes would appear N times.

Shape

• SchedulerRef(Target?, SchedulerName) spelled target/name as the client key, bare for this process so every existing link, test and handler keeps working; AddQuartzHttpClient binds under instanceId: targetName (the slot ISchedulerRepository reserved), target names unique per container.
• Merge rule: a clustered scheduler reached through N targets is shown once with N nodes when every target reports clustered + persistent and their QueryClusterNodes instance ids intersect (the gate matters: every non-clustered scheduler is NON_CLUSTERED). The merged entry is a ClusterAwareScheduler : IScheduler routing node-local members (Interrupt, InterruptFireInstance, Start/Standby/Shutdown, execution limits) to the owning node and cluster-wide reads to the first reachable one.
• SchedulerResource gains Target { get; init; } additively; the picker groups by target; the Schedulers page becomes the fleet table; the last selected key is remembered in the same preference store as the theme.

Done means

• Two QuartzSchedulers behind two targets are two rows; one cluster behind three agents is one row with three nodes and node-local actions land on the right node (a test with in-process cluster nodes over SQLite).
• SchedulerAuthorizationPolicy handlers that match on SchedulerName keep compiling and keep working.

Depends on the agent-target issue.

Part of #3387 — see the design record there for how this fits the whole.