Adds an opt-in `lock: true` per task, backed by a pluggable LockProvider set via
`cron.setLockProvider(...)`. node-cron ships no default provider — the guarantee
only holds with a real shared backend (e.g. Redis), so `lock` without a provider
throws.

- Key is `${name}:${fireTime}`, so it requires a dev-defined `name` (the
  generated id is per-process and can't coordinate). Throws if missing.
- The winner emits `execution:locked`, runs, releases, then emits
  `execution:unlocked`. A loser emits `execution:lockHeld` and skips.
- `acquire` failures are fail-closed (skip the run). `lockTtl` (default 30000)
  is a crash-safety expiry; it must exceed the run time.
- Guarantee: no concurrent execution across instances (effectively once with
  synced clocks) — not a hard exactly-once. `noOverlap` (in-process) is separate
  and unchanged.
- Not supported for background tasks (the provider can't cross the fork); throws.

Interface: `acquire(key, ttlMs): Promise<boolean>` + `release(key): Promise<void>`.

…rovider

Background tasks run in a forked daemon, so the lock provider (set in the
parent via setLockProvider) cannot cross the fork. The daemon now uses an
IpcLockProvider bridge: it asks the parent for the lock over IPC, the parent
runs the real provider and replies. Cross-fleet coordination still happens in
the shared backend (e.g. Redis) held by each instance's parent; IPC only
bridges the child to its own parent. A provider error is reported back so the
daemon fails closed (skips the run), mirroring the inline path. The daemon now
forwards execution:locked/unlocked/lockHeld.

Also adds a per-task `lockProvider` option that overrides the global one
(inline and background). createTask no longer rejects background + lock; it
requires a name and a resolvable provider (per-task or global).

Review follow-ups on the distributed coordination PR:

- Daemon exits on `process.on('disconnect')`. A forked daemon does not die
  with its parent — orphaned, it would keep running the schedule, and a
  distributed task's IPC shouldRun would hang forever with no parent to reply.
  Exiting on channel disconnect fixes both (the hang's root cause and a latent
  orphan bug), without a magic-number request timeout.
- Document that `maxExecutions` is counted per instance: with `distributed` and
  a per-fire coordinator, the fleet total can exceed it.
- Replace fixed sleeps in the daemon skipped-forwarding test with event-gated
  polling (waitFor) to remove real-timer flakiness.