feat(clients): add calendar weekly renewal and schedule previews (#6524)

* feat(clients): add calendar weekly renewal and schedule previews

Expose fixed-day, calendar-weekly, calendar-monthly, and disabled renewal
through one shared selector in individual and bulk client forms. Store the
weekly weekday separately (Monday 1 through Sunday 7) and use panel-local
calendar dates rather than a fixed 168-hour duration. Resolve skipped or
repeated midnights to the first valid instant of the selected date, and skip
an entirely nonexistent calendar date rather than changing the weekday.

Reuse the existing renewal writer and share its boundary alignment and
per-period catch-up calculation with an authenticated, read-only preview.
Keep monthly precedence for legacy records, fixed-day interval semantics,
maximum renewal allowances, first-use durations, and operator-disabled
settings unchanged. Selecting a mode does not rewrite an existing cutoff;
an unset calendar cutoff requires an explicit action to choose the first.
The last-valid-second preview uses the stored exclusive expiry, even when
the billing calculation aligns a legacy last-second cutoff up to midnight.

Carry weekly schedules through client persistence, paging, enable toggles,
inbound settings, and node traffic reconciliation. Migrate missing or nullable
weekday columns to disabled by default without altering existing limits, and
include the new isolated-schema PostgreSQL regression in the live CI gate.

Regenerate API contracts and reference documentation, add lifecycle and form
regressions, and document timezone, quota-reset, and upgrade considerations.
All participating nodes must be upgraded before weekly mode is enabled;
older binaries ignore the new field. Independent periodic traffic resets and
the optional month-end subscription-header display are not changed.

* fix(clients): validate renewal schedules across inbound write paths

Reject conflicting weekly/interval/monthly schedules and out-of-range
weekdays on inbound creation and edits, legacy one-client apply paths,
record/link synchronization, and traffic metadata writes. Validate imported
traffic snapshots as well, before any inbound or client is persisted, so
an inbound API cannot create a client that the clients page cannot toggle.

Merge a weekly-related schedule as one timestamp-selected tuple rather
than filling its zero fields from another renewal mode. Preserve empty
migration snapshots and the existing non-weekly monthly/interval merge
semantics. Renewal caps, counters, credentials, and deadlines are unchanged.

Add regressions for nine write paths, unchanged records and runtime calls
after rejection, valid inbound clients remaining editable, and duplicate
record merges between individually valid renewal modes.

* docs(clients): clarify depleted-client deletion risks on downgrade

Explain in English and Chinese that older versions not only stop weekly
renewal: their depleted-client cleanup can delete a weekly-only client once
its expiry or quota is exhausted. This is conditional on cleanup, not an
automatic deletion caused by downgrade itself.

Recommend backing up and converting weekly schedules to a mode supported
by every participating version before rollback, and avoiding cleanup while
mixed versions or unconverted clients remain. Merely disabling weekly
renewal does not restore the old binary's missing purge protection.

* fix(clients): bound weekly renewal date searches

Limit the search for a valid weekly calendar date to eight candidates so
an unusual timezone cannot monopolize the single traffic writer. Exhaustion
returns the original instant, allowing the existing catch-up forward-progress
guard to stop without advancing expiry, consuming an allowance, resetting
traffic, or falling back to a fixed-duration schedule that can drift.

Reject a non-future calendar suggestion in the read-only preview instead of
offering an immediately expired initial cutoff. Also report failed weekly
catch-up as a search error when allowances remain, not as cap exhaustion.
Existing preview errors use the form's current warning; no API schema or
locale changes are needed.

Exercise exhaustion with a synthetic valid TZif containing twelve skipped
Sundays. This fault-injection case was red without the bound; it is not a
claim that a production IANA timezone was observed hanging. Keep the Havana
and Apia regressions for real skipped/repeated midnights and absent dates.

* fix(tests): isolate weekly renewal preview timezone

Stop the weekly search regression from replacing process-global time.Local.
CI caught that assignment and its cleanup racing with background timer reads
through time.Now, even though the top-level tests do not use t.Parallel.

Pass the timezone and current instant into the unchanged preview calculation.
The public service still validates the request and resolves the panel timezone;
API responses, renewal accounting, and persisted client data are unchanged.

Use fixed dates for both suggestion and catch-up exhaustion, removing the
test's dependency on today's date and its unnecessary database setup. Keep a
bounded-lifetime background clock reader to expose future global-timezone
mutations under the existing race gate rather than disabling that check.

* ci: retrigger PR checks

Create an empty commit to request a fresh pull-request CI run after release dependency downloads failed with network errors.

No source, dependency, or workflow changes are included. Retry the existing checks without bypassing them.

* ci: retry PR checks and record deferred download hardening

Request another CI run after the amd64 release job compiled successfully but failed during dependency fetching with exit code 4 (network failure).

Record possible follow-up improvements for the Linux release fetch helper:
- Print each download URL and destination, and preserve error details.
- Reuse the existing curl configuration with up to five retries; add connection and per-attempt timeouts and a bounded retry window.
- Download to a temporary file and promote it to the final filename only after a successful, non-empty transfer. Keep the job failing if downloads ultimately fail.
- Validate successful downloads, recovery after a temporary failure, and correct failure after persistent errors before shipping such a change.

These improvements are intentionally deferred, not implemented or tested by this commit. This commit is empty: renewal logic, dependencies, workflow configuration, check requirements, and TLS verification remain unchanged.

---------

Co-authored-by: JacktheRanger <219502738+JacktheRanger@users.noreply.github.com>

docs/content/docs/en/config/clients.mdx

@@ -20,7 +20,7 @@ inbounds** at once, with per-client traffic accounting.
 | **Limit IP**   | all (except TUIC)     | Max simultaneous source IPs (enforced via Fail2ban).               |
 | **Total (GB)** | all (except TUIC)     | Traffic quota; the client is disabled when exhausted (for TUIC, limits are set at the inbound level). |
 | **Expiry**     | all                   | Date after which the client stops working.                        |
-| **Reset**      | all                   | Auto-renew period in **days** (rolls the quota over).              |
+| **Auto renewal** | all                 | Disabled, fixed interval in days, calendar weekly, or calendar monthly. |
 | **Telegram ID**| all                   | Links the client to a Telegram user for self-service/notifications.|
 | **Sub ID**     | all                   | Subscription identifier grouping this client's links.             |
 | **Group**      | all                   | Optional client group for organization and bulk filtering.        |
@@ -42,6 +42,68 @@ inbounds** at once, with per-client traffic accounting.
 - **Online status** and **last-online** times are tracked per client (and per
   node in multi-node setups).
 
+## Automatic renewal
+
+The individual and bulk-create forms offer one renewal mode at a time:
+
+| Mode | API fields | Schedule |
+| --- | --- | --- |
+| Disabled | `reset=0`, `resetDay=0`, `resetWeekday=0` | The expiry is not renewed. |
+| Fixed interval | `reset=N`, other two fields `0` | Add exactly N × 24 hours to the previous cutoff. |
+| Calendar weekly | `resetWeekday=1..7`, other two fields `0` | Renew at panel-local midnight on Monday (1) through Sunday (7). |
+| Calendar monthly | `resetDay=1..31`, `resetWeekday=0` | Renew at panel-local midnight on that day; missing dates clamp to the month's last day without losing the configured day. |
+
+Calendar weeks stay on the selected weekday across daylight-saving changes;
+they are not equivalent to a fixed seven-day interval. A skipped midnight uses
+the first valid instant of that date; a repeated midnight uses the first one.
+If a timezone skips the entire selected date, the next matching week is used.
+Existing monthly clients
+that also have `reset` set retain monthly precedence. The API rejects weekly
+renewal combined with a positive `reset` or `resetDay`.
+
+For a full calendar month, select **monthly, day 1** and set the initial cutoff
+to the next month's first midnight. For example, `2030-09-01 00:00:00` is valid
+through `2030-08-31 23:59:59`. Day 31 renews at the **start** of the 31st and is
+not the same schedule. The existing optional month-end subscription-header
+display remains a separate setting and is not enabled by this form.
+
+The preview uses the panel's timezone and the same calendar/catch-up calculation
+as automatic renewal. It shows the cutoff, last valid second, next expiry, and
+allowances needed. It is informational: it does not save, activate, reserve, or
+guarantee a future renewal. When no expiry is set, auto-renewal cannot run; an
+explicit button can set the first calendar cutoff. Selecting a mode alone never
+rewrites an existing expiry. First-use clients keep their initial duration, and
+their calendar dates are available after activation.
+
+For legacy last-second calendar cutoffs, the renewal boundary includes the
+existing free alignment to the following midnight. The last-valid-second
+preview still uses the **stored expiry**, not that alignment: an exclusive
+`23:59:59` cutoff is valid through `23:59:58`. Use a next-midnight cutoff for
+full-day validity; the preview itself does not repair the initial expiry.
+
+`resetMax=0` means unlimited renewals. A positive limit counts **each elapsed
+period**, including offline catch-up, not each scheduler tick or attached inbound.
+If the remaining allowances cannot reach a future cutoff, the client stays
+expired and its traffic is not reset. Operator-disabled clients stay disabled.
+
+Renewal already resets client traffic. The separate **periodic traffic reset**
+does not move the expiry and is unchanged; keep it disabled unless you intend an
+additional reset. Quarterly, yearly, and every-N-week/month schedules are not
+part of these modes.
+
+<Callout type="warn">
+  Upgrade the main panel and every participating node before enabling weekly
+  renewal. Older versions ignore `resetWeekday`; a weekly-only client would not
+  auto-renew and, after its expiry or quota is exhausted, can be deleted by
+  **delete depleted clients** because older versions lack the weekly protection.
+  Back up the database and convert weekly schedules to a renewal mode supported
+  by every participating version before downgrading. Merely disabling weekly
+  renewal does not protect a depleted client from deletion. Avoid depleted-client
+  cleanup while a mixed-version fleet or unconverted weekly clients remain.
+  Database upgrades default this new field to `0` and preserve existing limits
+  and dates.
+</Callout>
+
 ## Share links and external links
 
 Every client has share links and a QR code for its inbounds, plus a combined