Schedule-based snapshot generation driven by avni-server org config

### Background

Parent: avniproject/avni-client#1942. Today snapshot generation is initiated by `POST /requests`. For Phase 9 rollout, generation should be driven by an avni-server `OrganisationConfig` opt-in flag — when an org enables snapshot generation, snapshot-server picks them up on its next scheduled tick and processes their users.

The primary cadence control is per-org freshness, not the scheduler interval. The current implementation already follows this pattern (check once per ~24h per org; create if not present); this card carries it forward into the org-config-driven flow.

### Scope

- New avni-server `OrganisationConfig` flag: `enableSqliteSnapshotGeneration` (boolean, default false). Manageable via the existing webapp admin config UI.
- snapshot-server scheduler: periodic timer (short interval — minutes, not hours — to keep the loop responsive). Each tick:
- Read opted-in orgs from avni-server.
- For each opted-in org, evaluate per-user freshness and enqueue only users whose snapshot is stale.
- Process orgs **org-first**: drain one org's stale users before moving to the next.
- **Freshness gate (the rollout throttle):** skip regenerating a user if existing snapshot is newer than N hours (configurable; default 24h), snapshot-server commit SHA unchanged, and client schema version unchanged. Otherwise regenerate.
- Concurrent-run protection: if a previous tick is still in progress, the new tick skips.
- Remove `POST /requests` initiation path. Keep restart/cancel/observation endpoints as ops tools (they already exist; no new work on them).
- QA testing flow that currently uses `POST /requests` with `usernames` array → replaced by toggling the org config on a staging org. Document the new flow.

### Acceptance criteria

- [ ] avni-server: `OrganisationConfig.enableSqliteSnapshotGeneration` flag added, exposed via existing config API, manageable from webapp admin UI.
- [ ] snapshot-server reads opted-in orgs from avni-server at the start of each tick.
- [ ] Scheduler interval is configurable; default is short enough (minutes) to keep enqueue latency low. The 24h-per-user freshness gate is what prevents redundant regeneration — not a long scheduler interval.
- [ ] Within an org, users processed in recent-activity-first order, deterministic tiebreak by UUID.
- [ ] Across orgs, org-first ordering (configurable priority field; default oldest-opted-in first).
- [ ] Freshness check skips users with current snapshots; regenerates when SHA or schema version changed, or snapshot older than threshold.
- [ ] Two scheduler ticks cannot run concurrently; the second one no-ops with a log.
- [ ] `POST /requests` initiation is removed. Existing `GET /requests/:key`, `GET /requests/:key/users`, restart, cancel endpoints remain.
- [ ] QA flow documented: enable the flag on a staging org → wait for tick → verify output.
- [ ] When an org's flag flips on→off, scheduler stops enqueueing new work; in-flight users complete; no automatic cleanup of existing snapshots.

### Out of scope

- Round-robin-across-orgs (org-first is the default; switching to round-robin remains a config flip, not a rewrite).
- Time-of-day scheduling beyond a single cadence interval.