Add safe repeating-task support to task creation and editing

[deverman]

User outcome

Let users create or update repeating OmniFocus tasks through the compact task
creation and edit tools instead of managing repetition manually in OmniFocus.

Examples include weekly reviews, monthly bills, and reminders that repeat from
their assigned date or after completion.

Dependency

Implement after the edit-surface consolidation in #91 and task creation in #82
are stable. Extend those tools rather than adding a dedicated repetition tool.

Documented API basis

Omni Automation documents the writable task.repetitionRule property and the
Task.RepetitionRule constructor. Current OmniFocus versions support an ICS
recurrence rule plus schedule type, anchor date, and catch-up behavior. The
legacy repetition method parameter is deprecated when the newer schedule fields
are supplied.

Reference:
https://omni-automation.com/omnifocus/task-repeat.html

Scope to design and implement

• Read the current repetition rule through existing task field selection.
• Set or clear a repetition rule through edit_tasks.
• Set repetition when creating a task through add_tasks.
• Represent the documented current schedule type, anchor date, catch-up
  behavior, and ICS rule without exposing deprecated combinations.
• Validate the rule and required anchor/due/defer dates before saving.
• Preview the human-readable schedule and raw supported values before writing.
• Verify the saved rule and return compact repetition fields when requested.
• Define how completing or dropping a repeating occurrence is reported so the
  assistant does not confuse an advanced original task with a failed update.

Guardrails

• Use only the documented Omni Automation repetition APIs.
• Do not invent or silently repair an invalid ICS rule.
• Reject deprecated/current parameter combinations that OmniFocus rejects.
• Require explicit confirmation before replacing or clearing an existing rule.
• Keep repetition optional so ordinary task schemas and responses remain
  compact.
• Do not combine this work with creation, tool consolidation, transport, or
  query optimization in one branch.

Acceptance criteria

• A task can be created with a verified repeating schedule.
• An existing task can have its repetition set, replaced, or cleared.
• Regular schedules and schedules based on completion are distinguishable.
• Invalid rules and unsupported combinations fail before changing OmniFocus.
• Preview describes the resulting schedule accurately.
• Readback matches the rule stored by OmniFocus.
• Completion behavior for a repeating task reports the resulting occurrence and
  stable IDs truthfully.
• Swift Testing and reversible live integration tests cover set, replace, clear,
  invalid, and completion-advance cases.
• MCP/CLI parity and compact catalog-size gates remain satisfied.

[deverman]

Fork review follow-up: implement schedule awareness before schedule mutation

The Lumenbeing/FocusRelayMCP fork independently added partial repetition
readback in
1ddd031
and corrected Omni enum extraction in
6c31d65.
Thanks to @Lumenbeing / @Defiantweb for demonstrating that assistants need to
understand recurring work, not merely create it.

The product intent is safe schedule awareness: before an assistant edits,
completes, drops, or recreates a repeating task, it should know the complete
schedule and explain whether the operation advances an occurrence.

Implement #93 as separately validated vertical slices after #91, #82, and #129
are stable:

1. Read foundation (query/server-wire) — expose complete optional
   repetition metadata through list_tasks and get_task.
2. Creation (mutation) — create and verify a repeating task through
   add_tasks without a dedicated public tool.
3. Edit (mutation) — set, replace, and clear repetition through
   edit_tasks, with explicit confirmation for replacement/clear.
4. Lifecycle (mutation) — report completion and drop behavior truthfully,
   including the completed/dropped occurrence and the advanced active
   occurrence IDs.

Read-model constraints clarified by the fork review:

• Prefer one structured optional repetition value over three unrelated string
  fields. It must contain ruleString, scheduleType, anchorDateKey, and
  catchUpAutomatically.
• Keep the raw ICS rule exact; do not silently normalize or repair it.
• Map Omni enum constants explicitly. Do not use .name and do not expose
  implementation-specific String(enumObject) output for unknown values.
• Define version behavior for the v4.7+ schedule fields. Missing APIs must be an
  explicit compatibility result, not an empty string that looks valid.
• A non-repeating task returns repetition=null.
• Read task.repetitionRule only when requested or required by a lifecycle
  operation so ordinary list results remain compact.
• Include catchUpAutomatically; the fork's partial model omitted behavior that
  can change which occurrence becomes current.
• Add tool-description and direct MCP field/wire coverage so models can discover
  the optional field.

Additional acceptance journey:

1. The user asks to complete a recurring task.
2. The assistant reads the task with repetition metadata and explains that
   completion will advance it according to its schedule.
3. After approval, FocusRelay completes the occurrence, verifies the resulting
   active occurrence, and returns both stable IDs and the preserved schedule.
4. The assistant does not report the advanced original as a failed completion or
   create a duplicate replacement task.

Required read fixtures include no rule, Regularly, FromCompletion, each
documented anchor, catch-up true/false, exact RRULE preservation, unknown/version
behavior, field omission, list_tasks, get_task, CLI, and direct MCP output.
Mutation slices retain the issue's reversible live set/replace/clear and
occurrence-advance requirements.