fix(certificate-authority): preserve Daily schedule variant on read/update

[spbsoluble]

Summary

• full_scan/incremental_scan/threshold_check schedules can be Interval-shaped or Daily-shaped server-side; the provider only understood Interval, so a Daily-shaped schedule read back as Null (indistinguishable from "no schedule").
• Because the update endpoint is a full-replace PUT, an omitted schedule field clears it server-side — so any CA using a Daily schedule was silently wiped on every apply, not just the first one.
• Adds full_scan_daily_time / incremental_scan_daily_time / threshold_check_daily_time (RFC3339, mutually exclusive per-schedule with the existing *_interval_minutes attribute), new scheduleToState/buildSchedule helpers, extends preserveCAUpdateFields so an update declaring neither variant preserves whichever the prior state holds, adds ValidateConfig to reject conflicting/malformed schedule config, and updates Delete()'s schedule-clearing path to null out the new attributes too.

Verification

• go build ./... clean; full TestUnit suite: 0 failures, 1 skip (expected baseline).
• New regression tests: TestUnitCAReadPreservesDailySchedule, TestUnitCAUpdatePreservesDailySchedule, TestUnitCAUpdateScheduleVariantSwitchDoesNotResurrectOther, TestUnitCAValidateConfigRejectsConflictingScheduleAttributes, TestUnitCAValidateConfigRejectsMalformedDailyTime, TestUnitCAValidateConfigAllowsEitherVariantAlone.
• Confirmed live against the lab's real CA (id 1, "Sub-CA"): pre-fix, an ordinary import + apply wiped its live daily full_scan schedule. Post-fix, the same import + apply shows 0 changes and correctly populates full_scan_daily_time — schedule survives.
• docs/resources/certificate_authority.md regenerated for the three new attributes.

Base branch

Targets fix/template-role-binding-pagination (#173), not v2 — stacking on top of the pending pagination fix per current release sequencing.

[spbsoluble]

Automated high-effort code review (workflow-backed, 4 finders + independent verification per candidate) surfaced 2 confirmed correctness defects, both in the schedule variant-handling logic this PR is meant to fix. Details inline — these should block merge pending a fix, even though GitHub won't let me formally request changes on my own PR. A separate compliance pass (SOX/SOC2/SOC1) also flagged a High-priority logging gap in the same preserve/override path — noted below for visibility even though it's not blocking.

Compliance finding (High, not inline-commented): preserveCAUpdateFields/preserveSchedule (~lines 931-961, called at ~1088) emits no tflog call for which of the three outcomes occurred (kept plan value / preserved prior Interval / preserved prior Daily) per schedule — this is the exact code path that caused the original incident, so there's still no audit trail for schedule changes from logs alone. Delete() already logs its schedule-clearing decision (~line 1157); recommend matching that pattern here. Medium: ValidateConfig's rejection paths only raise Terraform diagnostics, no tflog.Warn, so rejected config leaves no trace in TF_LOG.

[spbsoluble]

[CONFIRMED, correctness] preserveSchedule's "either variant known → bail" guard is defeated by this same schema's UseStateForUnknown() plan modifiers on the paired *_interval_minutes/*_daily_time attributes (also relevant: line 941, buildSchedule's Interval-wins precedence at ~line 669, and the schema modifier at ~line 366).

Failure scenario: A CA has full_scan_interval_minutes = 60 in state (full_scan_daily_time unset/Null). User edits config to remove full_scan_interval_minutes and add full_scan_daily_time = "2026-07-17T15:46:00Z" to switch the schedule to Daily. Because full_scan_interval_minutes is Optional+Computed with UseStateForUnknown(), Terraform's plan reverts that field to the old Known value 60 instead of Null. Update() then sees both plan.FullScanIntervalMinutes=60 (Known) and plan.FullScanDailyTime="2026-07-17T15:46:00Z" (Known). The if planIntervalKnown || planDailyKnown { return } guard fires and preserves nothing useful, then buildSchedule's Interval-precedence branch wins — the outbound PUT still sends the old Interval schedule and silently drops the user's Daily config. Either the CA's live schedule never actually switches, or Terraform raises "Provider produced inconsistent result after apply" because planned full_scan_daily_time (Known) doesn't match the Null value scheduleToState derives from the server's still-Interval response.

This defeats the core purpose of this PR in the variant-switch case — worth a regression test alongside the existing TestUnitCAUpdateScheduleVariantSwitchDoesNotResurrectOther, which appears not to cover the case where the old variant's attribute is still Known in the plan due to UseStateForUnknown.

[spbsoluble]

[CONFIRMED, correctness] scheduleToState unconditionally reformats a returned Daily schedule time via .UTC() (sched.Daily.Time.UTC().Format(time.RFC3339)), so a user-configured *_daily_time with a non-UTC offset can never round-trip back to the same string.

Failure scenario: User sets full_scan_daily_time = "2026-07-17T15:46:00-04:00" — accepted as valid by validateCAScheduleAttributes, which only calls time.Parse without requiring UTC. buildSchedule sends that instant to Command; on read-back, scheduleToState formats it as "2026-07-17T19:46:00Z" — a different string than the planned/config value. Since full_scan_daily_time is Optional (its planned value is the user's literal Known string, not Unknown), this mismatch triggers "Provider produced inconsistent result after apply" on the apply that sets it, or a perpetual diff/re-apply loop on every subsequent plan.

Fix options: either normalize/require UTC in validateCAScheduleAttributes (reject non-Z offsets with a clear error) or preserve the original offset through the round-trip instead of forcing .UTC().