Run the universe-bible describe/render actions as on-demand scheduled tasks

[atomantic]

Summary

• The two programmatic Quota Burn actions — filling blank universe bible sheets and rendering entries that have no image — are now ordinary on-demand scheduled tasks. They appear in CoS → Schedule with their own settings and a Run Now button, and Quota Burn dispatches the same handler instead of a burn-private executor.
• Implementations move to server/services/scheduledHandlers/; quotaBurnJobs' JOB_MODULES points at them, so there is one implementation, not a quota-only copy that drifts. JOB_MODULES itself stays (retiring it is Migrate legacy Quota Burn prompt plans to scheduled-task references and retire JOB_MODULES #6381).
• The burning family is the discriminator: present ⇒ the provider / render backend is pinned to the subscription being drained (a family that can't be pinned is refused, never redirected); absent ⇒ an ordinary run resolves like any other scheduled task (the task's own pin, else the install's active provider and the universe-bible render-target ladder). resolveDescribeProvider / resolveRenderMode now return { value, reason } so "nothing pinned" can't collapse into "refuse to spend".
• Both ship enabled, ON_DEMAND, with no interval and no cron — never clock-due, so a fresh install spends nothing until someone presses Run. Shipped taskMetadata params mirror the Quota Burn catalog row (guarded by a parity test) and are allow-listed in sanitizeTaskMetadata.
• The side-effect-free probe and the opaque probe→run context handoff are preserved: probing writes nothing, enqueues nothing, and calls no provider; a run with context: undefined still does its own scan.
• The two CoS on-demand engines drain these ahead of their slot-bounded loops (a handler uses no spawn slot) and gate on the request claim, so one Run Now can't be run twice by both engines.
• UI: no app picker for a programmatic task (the server rejects an app target — a universe is not a repo), no prompt editor (there is no prompt), and a toast reporting what the handler actually did, since no agent task appears to watch.
• docs/QUOTA-BURN.md updated for the moved paths and the "add a new programmatic action as a scheduled handler" guidance.

Test plan

• cd server && npm test — 2012 files / 39,990 tests pass, including the import-scoping budget.
• cd client && npm test — 870 files / 10,585 tests pass.
• New/extended coverage:
  • taskSchedule.test.js — both types are enabled ON_DEMAND with no cadence, never due however much time has passed, refuse a managed-app target, and carry no prompt template.
  • taskScheduleRegistry.programmatic.test.js — the type list matches the handler registry, JOB_MODULES resolves to the same module object, shipped params match the burn catalog and survive sanitization, and out-of-contract params are dropped.
  • scheduledHandlers/universeBible{Describe,Images}.test.js — carried over unchanged, plus probe→run context reuse (asserted by counting the universe walk), a run with no context, a probe that writes/enqueues/prompts nothing, and the no-family scheduled path.
  • cosTaskGenerator.programmaticOnDemand.test.js — the manual path runs the handler once with the task's saved settings and force: true, clears without running when the type is disabled or Improve is off, reports its outcome, leaves agent types alone, and skips when the sibling engine already claimed the request.
  • RunTaskButton / PromptEditor / useOnDemandTaskToast client cases for the three UI surfaces.

Closes #6376