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/zh/config/clients.mdx

@@ -19,7 +19,7 @@ icon: Users
 | **Limit IP**   | 全部（TUIC 除外）      | 最大同时连接的源 IP 数量（通过 Fail2ban 强制执行）。             |
 | **Total (GB)** | 全部（TUIC 除外）      | 流量配额；用尽后客户端将被禁用（对于 TUIC，限制在入站级别设置）。 |
 | **Expiry**     | 全部                  | 该日期之后客户端停止工作。                                       |
-| **Reset**      | 全部                  | 以**天**为单位的自动续期周期（滚动重置配额）。                   |
+| **自动续期**   | 全部                  | 关闭、固定天数、日历每周或日历每月。                             |
 | **Telegram ID**| 全部                  | 将客户端关联到 Telegram 用户，用于自助服务/通知。               |
 | **Sub ID**     | 全部                  | 用于对该客户端链接分组的订阅标识符。                             |
 | **Group**      | 全部                  | 可选的客户端分组，便于组织管理和批量筛选。                       |
@@ -39,6 +39,58 @@ icon: Users
   并从该客户端的操作中清除它们。
 - 系统会按客户端（在多节点部署中还会按节点）跟踪**在线状态**和**最后在线**时间。
 
+## 自动续期
+
+单个客户端和批量创建表单使用统一的续期模式选择：
+
+| 模式 | API 字段 | 续期规则 |
+| --- | --- | --- |
+| 关闭 | `reset=0`、`resetDay=0`、`resetWeekday=0` | 不自动延长到期时间。 |
+| 固定天数 | `reset=N`，另两个字段为 `0` | 从上次截止时间增加 N × 24 小时。 |
+| 日历每周 | `resetWeekday=1..7`，另两个字段为 `0` | 在面板时区每周一（1）至周日（7）的零点续期。 |
+| 日历每月 | `resetDay=1..31`、`resetWeekday=0` | 在面板时区指定日的零点续期；短月取月末，之后仍按原配置日续期。 |
+
+日历每周跨夏令时仍保持指定星期，不等于固定 7 天。若零点不存在，使用
+该日期第一个有效时刻；零点重复时取第一次。若时区跳过整天，则使用
+下一周的同一星期。旧配置同时填写
+`reset` 和 `resetDay` 时继续以每月续期为准。API 不允许每周续期与正数
+`reset` 或 `resetDay` 同时启用。
+
+整自然月应选**每月、1 日**，首次截止时间设置为下月 1 日零点。例如
+`2030-09-01 00:00:00` 表示有效至 `2030-08-31 23:59:59`。
+31 日表示在 31 日**开始时**续期，并不是同一边界。订阅头原有的可选
+月末显示设置仍独立存在，本表单不会自动开启它。
+
+日期预览使用面板时区和后端实际续期的同一套计算，显示截止时间、最后
+有效秒、下次到期时间及需要消耗的续期次数。预览不会保存、激活或预留
+续期，也不保证未来一定续期。未设到期时间时自动续期无法运行，可以
+明确点击按钮设置首次日历截止时间；仅选择模式不会修改已有到期时间。
+“首次使用后开始”保留原来的初始天数，激活后才能确定日历日期。
+
+旧配置以最后一秒为日历截止时间时，续期边界包含原有的不计次数向下个
+零点对齐规则。但最后有效秒仍按**已存储的到期时间**计算，不会假装
+初始时间已被修改：排他截止时间 `23:59:59` 实际有效至 `23:59:58`。
+整天有效应使用下一个零点，预览本身不会修复首次截止时间。
+
+最大续期次数 `resetMax=0` 表示不限次数。正数上限按**每个经过的周期**
+计数，包括离线补续，不按定时任务执行次数或关联入站数量计数。剩余
+次数不足以续到未来时，客户端继续过期且不会重置流量；手动禁用的
+客户端保持禁用。
+
+自动续期本身会重置客户端流量。独立的**定期流量重置**不延长到期时间，
+这次未改变其规则；除非需要额外重置，否则保持关闭。本次不包含季度、
+年度和每 N 周/月的续期。
+
+<Callout type="warn">
+  启用每周续期前，需要升级主面板及所有参与节点。旧版本会忽略
+  `resetWeekday`，仅配置每周的客户端将无法自动续期，且在到期或流量
+  耗尽后，可能被**删除已耗尽客户端**操作删除，因为旧版没有每周续期
+  的清理保护。降级前应备份数据库，并将每周配置转换为所有参与版本
+  都支持的续期模式；仅关闭每周续期并不能防止耗尽后的删除。存在
+  混合版本或尚未转换的每周客户端时，应避免执行耗尽客户端清理。
+  数据库升级默认将新字段设为 `0`，保留已有日期和限制。
+</Callout>
+
 ## 分享链接与外部链接
 
 每个客户端都有针对其各入站的分享链接和二维码，外加一个合并的