Problem

Fixes #3106.

When configuring named schedulers under Quartz:Schedulers:{name} and calling the named AddQuartz overload with the root Quartz section, nothing is registered (0 jobs, 0 triggers):

// FAILS today — registers 0 jobs, 0 triggers
services.AddQuartz("LocalScheduler", Configuration.GetSection("Quartz"), _ => { });

// Worked only with the scheduler-specific section
services.AddQuartz("LocalScheduler", Configuration.GetSection("Quartz:Schedulers:LocalScheduler"), _ => { });

The named overload assumed the section it received was the scheduler's own section, so it read flat properties and the Schedule/Scheduling sub-sections directly under it. With the root section those live under Schedulers:{name}:..., so they were never found (properties were lost too, since Schedulers is a reserved/skipped key).

Fix

• Named overload auto-resolves the sub-section: AddQuartz(name, configuration) now resolves a Schedulers:{name} child when present and uses it for both property conversion and JsonSchedulingHelper; otherwise it uses the section as-is. Fully backward-compatible — the recursive call from the root overload and the existing flat-section usage are unaffected.
• Clear error for an ambiguous mix: the root AddQuartz(IConfiguration) overload now throws a SchedulerConfigException when a top-level Schedule/Scheduling section is combined with a Schedulers sub-section. Previously that top-level scheduling data was silently dropped (it has no scheduler to attach to once named schedulers are in play).

Tests & docs

• New AddQuartz_NamedScheduler_WithRootSectionContainingSchedulers_ResolvesSubsection (reproduction).
• New AddQuartz_SchedulersWithTopLevelSchedule_Throws (guard).
• Documented both behaviors in the JSON configuration docs.

All JsonSchedulingTests pass.

🤖 Generated with Claude Code