feat(scheduler): add Scheduler for centralized cron job management

[Lucasjapa]

Introduce opt-in job registration via schedule() and register(). Each Scheduler instance owns an isolated JobRegistry for lifecycle control, status queries and graceful shutdown.

• add JobRegistry for per-instance job storage and execution counting
• add Scheduler with schedule, register, lifecycle and query methods
• export Scheduler singleton, ScheduleParams and RegistryEntry types
• add Jest tests and runnable examples under examples/scheduler/
• document Scheduler API in README

Description

Introduce opt-in job registration via schedule() and register(). Each Scheduler instance owns an isolated JobRegistry for lifecycle control, status queries and graceful shutdown.

• add JobRegistry for per-instance job storage and execution counting
• add Scheduler with schedule, register, lifecycle and query methods
• export Scheduler singleton, ScheduleParams and RegistryEntry types
• add Jest tests and runnable examples under examples/scheduler/
• document Scheduler API in README

New API

Scheduler / scheduler

• schedule(params) — creates a CronJob, registers it, then applies runOnInit and start
• register(name, job) — registers an existing CronJob (opt-in, never automatic)
• Lifecycle: start, stop, startAll, stopAll, remove, unregister, clear
• Queries: getJobNames, getJob, getJobInfo, getActiveJobs, getInactiveJobs, getPending, nextJobs

Design decisions

• Registration is opt-in — passing name to CronJob alone does not register the job
• Each Scheduler instance has its own registry (isolated for tests and workers)
• lastExecution is derived from job.lastDate() to avoid duplicated metadata
• remove() stops and unregisters; unregister() only removes from the registry

Related Issue

N/A — feature extension discussed and implemented locally. Happy to open a feature request issue if maintainers prefer tracking before merge.
URL: #871

Motivation and Context

The node-cron library is intentionally low-level: each CronJob is managed individually. In real applications with multiple scheduled tasks, developers typically reinvent a Map to track jobs, handle graceful shutdown, and expose health-check information.

This PR adds an optional management layer on top of the existing CronJob API without changing its behavior. Apps that only need a single job can continue using CronJob directly; apps with multiple jobs gain centralized lifecycle and query capabilities.

How Has This Been Tested?

Environment: Node.js v20.12.2, Linux, TZ=Europe/Paris (Jest default for this repo)
Unit tests (tests/scheduler.test.ts — 14 cases):
npm run test -- tests/scheduler.test.ts

Screenshots (if appropriate):

N/A — backend/library change, no UI.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have added tests to cover my changes.
• All new and existing tests passed.
• If my change introduces a breaking change, I have added a ! after the type/scope in the title (see the Conventional Commits standard).