Persist per-user scheduler search rate-limit learning across runs

Preserves only the scheduler residual of #3656. The current authenticated api_v1 context helper already selects DB-backed tracking and rejects client control of its reserved programmatic_mode; retain that behavior. In contrast, scheduler.background supplies username, password, and a settings snapshot to quick_summary but omits the explicit opt-in, leaving the programmatic default to use per-instance memory tracking.

Acceptance criteria:

• Explicitly select database-backed tracking for authenticated scheduled/subscription research that already has an encrypted user-database context. Carry current user settings and keep lifecycle/credential handling within existing scheduler contracts.
• Demonstrate that a second scheduled run for the same user reuses learned engine delay/rate-limit state; another user must not inherit it.
• Preserve caller behavior without a user database, current REST enforcement, configured rate limits, and safe cleanup on provider failure/cancellation.
• Add a regression against the real scheduler call path plus persistence/isolation tests across separate engine/run instances.

Recreate this focused scheduler change rather than merging the old 1,137-file / 467-conflict branch. The REST portion is already superseded and must not be reintroduced with weaker client overrides.

Start with the authenticated api_v1 context helper and scheduler.background, then trace how the username, credentials, settings snapshot, and quick_summary call handle programmatic mode. Recreate the focused scheduler behavior without changing REST enforcement, and add regression tests for the real scheduler path, persistence across separate runs, per-user isolation, no-database behavior, and cleanup after failure or cancellation.