Execution groups allow each scheduler node to limit how many threads
a category of job can consume concurrently, preventing resource-intensive
jobs from starving lightweight work.

A trigger is optionally tagged with an execution group via
TriggerBuilder.WithExecutionGroup("batch-jobs"). Per-node limits are
configured through properties (quartz.executionLimit.*), DI
(UseExecutionLimits), or the runtime API (SetExecutionLimits extension).

Implementation uses the established 3.x opportunistic patterns:
- INextVersionTrigger for the ExecutionGroup property
- INextVersionJobStore for execution-limit-aware trigger acquisition
- INextVersionDelegate for ADO column probing and SQL filtering
- SchedulerExtensions for the public scheduler API

The scheduler thread tracks running counts per execution group by
wrapping job execution delegates, requiring zero IThreadPool changes.
RAMJobStore filters candidates in-memory; ADO job store probes for
an optional EXECUTION_GROUP column and applies SQL + in-memory filtering.

Includes Dashboard UI (execution group column/filter on trigger and
currently-executing pages), documentation (tutorial, config reference),
database migration scripts, and unit tests.

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- Always track execution group counts unconditionally so limits enabled
  at runtime see accurate in-flight counts immediately
- Downgrade missing EXECUTION_GROUP column log from Warn to Debug (only
  relevant when execution groups are actually used)
- Hoist rs.GetOrdinal() out of the per-row loop in SelectTriggerToAcquire
- Validate configure delegate is not null in UseExecutionLimits
- Reject reserved keys ("" and "*") in ForGroup/Unlimited with clear
  error message directing to ForDefaultGroup/ForOtherGroups
- Normalize empty/whitespace execution group to null in TriggerBuilder
- Fix test for "null" value alias and add coverage for "_" key alias

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- Exclude default (null) group from OtherGroups fallback so configuring
  quartz.executionLimit.* = N does not implicitly cap ungrouped triggers
- Use INextVersionTrigger instead of AbstractTrigger in TriggerBuilder to
  avoid coupling public API to implementation types
- Remove zero-count entries from runningExecutionGroupCounts to prevent
  unbounded growth with high-cardinality group names
- Clarify docs: QRTZ_FIRED_TRIGGERS column is for forward compatibility
  only (not currently read/written), fix log level description

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

…ult group

- Reject negative values in ParseExecutionLimits with SchedulerConfigException
  instead of letting ArgumentOutOfRangeException escape from the model
- Skip OtherGroups fallback for the default (ungrouped) key in
  ComputeAvailableExecutionGroupLimits, matching the CheckExecutionLimits
  semantics where "*" only applies to named groups

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- Restore original 3-parameter TriggerAcquireResult constructor as an
  overload forwarding to the new 4-parameter one, preserving binary
  compatibility for custom IDriverDelegate implementations
- Wrap execution limits API assertions in SmokeTestPerformer with
  try/catch for SchedulerException so the test works with remote proxy
  schedulers that don't support execution limits

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- GetExecutionLimits returns a snapshot through the public API path
  (StdScheduler) while the internal QuartzScheduler path stays
  zero-copy for the scheduler thread hot path
- Use INextVersionTrigger instead of AbstractTrigger in
  QuartzSchedulerThread for reading ExecutionGroup
- Move UseExecutionLimits from IServiceCollectionQuartzConfigurator
  interface to an extension method to preserve binary compatibility
  for external interface implementations

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- Replace all AbstractTrigger casts for ExecutionGroup with
  INextVersionTrigger in RAMJobStore, StdAdoDelegate (insert, update,
  select), keeping the feature decoupled from concrete trigger types
- Remove unused 'using Quartz.Impl' from ServiceCollectionQuartzConfigurator
- Clarify docs: ADO job stores need the EXECUTION_GROUP column for
  persistence; without it triggers appear ungrouped after restart

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- Move GetExecutionLimits from IQuartzApiClient to a separate
  IQuartzApiClientExecutionLimits interface to avoid breaking external
  implementations
- Change TriggerHeaderDto and CurrentlyExecutingJobDto to use init-only
  ExecutionGroup property instead of adding constructor parameters,
  preserving binary compatibility for existing consumers
- InProcessQuartzApiClient implements IQuartzApiClientExecutionLimits
- Use INextVersionTrigger instead of AbstractTrigger in dashboard client

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>

- TriggerBuilder.WithExecutionGroup trims whitespace and rejects "*"
- AbstractTrigger.ExecutionGroup setter normalizes whitespace to null
  and trims valid values
- Document "null" as case-insensitive key alias for "_" (default group)
  in configuration reference, distinct from value "null" (unlimited)
- Add test for quartz.executionLimit.null key alias

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>