✨🧑‍💻 - Implement durable recurrence execution and calendar queries after the planning foundation #20

Description of the idea or improvement

Continue the complete durable recurrence/calendar backend contract from issue #17 after its owner-approved temporal/rule/planning checkpoint in PR #19. Preserve specs/recurrence-calendar.md and specs/recurrence-execution-foundation.md, all eight RCE requirements, all52 companion cases and all37 original owner cases. The first all-domain release, complete UI/HA calendar surfaces and both deployments remain required; this continuation does not declare them accepted.

Implement current-authorized scheduled creation and reviewed attachment without duplicating an existing first task, persistent fixed and completion-relative schedules, schema8, unique nominal slots, atomic tasks/progress/receipts/audit/outbox, bounded production materialization in native and standalone, lifecycle inbox/cycle closure, restart/concurrency/crash behavior, historical restore non-recreation, pause/resume/skip/reschedule and preview/apply, genuine task classification/date-only/planned/deadline facts, bounded protected calendar queries and strict HTTP contracts. Retain the existing actual-work relative anchor, configured single fold, first-valid gap/whole-date adjustment and collision-review behavior.

SQLite schema8 still belongs to recurrence execution; participant administration follows only after the actual schema8 merge with schema9. The already-merged model checkpoints did not implement either migration. Preserve supported historical schemas1..7, original fixture bytes, ownership/channel/generation fences, original receipts and compatible whole application/database rollback. Keep actual technical maintenance capability separate from current human proof and all human permissions; no request selects its principal, installation or channel. Provider outages, stale previews and original-result recovery retain current authorization and explicit unavailable/conflict/historical states.

All newly implemented first-party source requires tests first and complete global/per-module coverage, strict typing, Clean Architecture/import/privacy negatives, real SQLite concurrency/rollback/restart/restoration tests, applicable browser/OpenAPI/image tests, and every-PR CI Check. Merge requires no unresolved Bugbot finding. Copilot defects are reported upstream rather than modifying Copilot resources/configuration or relaxing scope/coverage. Existing gateway remains untouched; Domus later exposes only its services/entities.

Current limitations or challenges

Verified develop3131810082760a98ee4af66f11bb65eaac49cc3b, tree c18c57b60e20ccbc83d61464ab5fe623c8ed1713, contains the owner-approved merges #18 and #19. Its tree is byte-identical to the reviewed/tested synced head580ab11. The combined source passes3398 backend tests/117 authored modules at100% statement and branch coverage; this is foundation evidence, not recurrence execution acceptance. The merged foundation has strict rule validation, finite original frequency periods, timezone resolution and side-effect-free planning. The actual database remains schema7. It has no recurrence tables, durable materializer, lifecycle consumer, calendar query/API or composed runner. Planning cursors are values, not persisted execution proof. Current immutable owner Edge.5 images do not invoke these modules.

Five initial SQLite source/test/fixture files were prepared before the owner-requested checkpoint merge and are preserved privately with exact base/source hashes and a Git stash. They have only an initial expected missing-symbol test failure and are not claimed implemented, passing or publishable. Resume them only on this continuation's exact Action-created admitted branch after its required SDD update. The new synthetic schema7 fixture was generated under source64908ee before DDL changes (SHA256 c5ca7b2383e9f75561a59b9ea0bbbd98736ae400b19e735b5a6fdf90ca139ea5); existing1..6 fixtures stay immutable.

Expected impact

Configured responsibilities become actual durable household tasks, with explicit bounded progress and truthful calendar facts across both persistent runtimes. Restart, concurrent workers and compatible restoration cannot duplicate already-processed work. Subsequent calendar screens and HA entities consume the same owned scheduling model.

Additional context or comments

This is the unfinished portion of #17, not a replacement or reduction of its accepted requirements. Reference the existing companion rather than duplicating the owner. No new owner decision is pending. Authoritative source paths include backend/src/domus/application/fixed_recurrence.py, backend/src/domus/application/recurrence_ports.py, backend/src/domus/domain/recurrence_rules.py, backend/src/domus/domain/recurrence_planning.py, backend/src/domus/domain/nominal_recurrence.py, backend/src/domus/infrastructure/recurrence_time.py, backend/src/domus/infrastructure/sqlite.py and the existing task/source/restore seams. Declare actual new implementation paths as create before committing them. The Action exclusively owns admission and remote branch creation/synchronization. No owner HA update, deployment, release/tag or Copilot change is implied by starting this work.

Use the actual immutable development base above, not bootstrap master. This is a continuation of now-closed #17 after an explicitly partial checkpoint merge; preserve every unfinished owning requirement rather than treating its closed/100% lifecycle labels as full feature acceptance. Publication recovery decision, explicitly approved by the maintainer: create the companion specs/recurrence-storage-continuation.md under the existing recurrence-calendar capability. Retain specs/recurrence-execution-foundation.md and specs/recurrence-calendar.md verbatim. The proper bounded update was supplied after a terminal size failure, but its one normal retry also exhausted the 18,000-character response bound. Use the supported new companion route rather than another unchanged appendix retry. The new companion carries the actual current baseline/path declarations and four independent storage refinements; it references all eight retained RCE requirements, all 52 retained companion cases and all 37 original owner cases, which remain required and must not be redefined as new cases. Full continuation scope remains exactly as above. All retained specifications and the new companion remain Draft until real implementation acceptance. The complete proposed raw companion is supplied in the issue comments as review input; normal Action validation, catalog registration, publication and exact managed-branch readiness remain mandatory.

Drafting notation clarification after the terminal repository-path failure in run 41351108619: preserve the explicitly approved companion route. In inline code, use slash-bearing text only for exact existing or section-15-declared repository files. Write deployment alternatives (native and standalone, Stable and Edge, UI and HA), schema ranges and future parent directories as ordinary prose. If an HTTP/MIME example is necessary, use a method/header label with whitespace (for example Content-Type: application/json), without changing actual runtime URL semantics. Do not invent file globs/ranges or cite an undeclared future module. Use the exact current/proposed paths from the complete companion's section 15; any additional intended new file must first be declared as create there. This changes documentation notation only: all retained scope, four new cases, 52 companion cases and 37 original owner cases remain required. Original modules reproduced the known protocol-notation classification independently, but the rejected generated candidate remains unavailable; its actual offending reference is unknown. No validator or runtime behavior is being changed.