A single scheduled recipe can run more than once for the same cron occurrence

**Describe the bug**

A single schedule can fire more than once for the same cron slot.

`swisssync-prod-triage` is stored once (`cron: 15 8 * * *`), but Desktop's Schedule Details still showed extra sessions for that job. One extra run started at 08:45 instead of 08:15, from a different working directory than the recipe.

Two overlapping causes:

1. Every `goose serve --enable-scheduler` process starts its own `tokio-cron-scheduler` against the same `schedule.json`. Extra Desktop windows / CLI `schedule` commands can therefore all fire the same job.
2. Cron callbacks did not claim the current occurrence. A delayed tick after a missed slot could still execute the previous occurrence, and `currently_running` was only in-memory.

---

**To Reproduce**
Steps to reproduce the behavior:
1. Create one daily schedule, e.g. `15 8 * * *`.
2. Keep Goose Desktop running with `--enable-scheduler`.
3. Also start another Goose process that constructs `Scheduler::new` against the same `schedule.json` (second Desktop window, or `goose schedule list` / `run-now`), or miss the exact minute so a later tick catch-up can fire.
4. Open Schedule Details for that job.
5. See more than one session for the same scheduled slot, sometimes at an off-cron time such as 08:45.

---

**Expected behavior**

Each cron occurrence runs at most once. Extra processes and late catch-up ticks should skip a slot that was already claimed.

---

**Please provide the following information**
- **OS & Arch:** macOS arm64
- **Interface:** UI
- **Version:** current main (`goose serve --enable-scheduler`)
- **Extensions enabled:** n/a (scheduler)
- **Provider & Model:** n/a

---

**Additional context**

Observed sessions for `swisssync-prod-triage`:

- Aug 31 08:15 — expected
- Aug 30 08:45 — late catch-up, cwd was a goose worktree rather than the recipe dir
- Aug 29 08:15 — expected
- Aug 28 08:15 — expected

Root cause is in `crates/goose/src/scheduler.rs`: cron callbacks only checked `paused`, then set `last_run` / `currently_running` without a cross-process claim or occurrence skip.

Fix in https://github.com/aaif-goose/goose/pull/11694: claim the current slot under `schedule.json.lock`, skip if `last_run` already covers that occurrence or the job is in-flight, and ignore ticks more than two minutes after the scheduled time.

Do not begin implementation until the issue reaches **Ready** on the [Goose Issues board](https://github.com/orgs/aaif-goose/projects/1).