Expires field rejects retention periods longer than 99 hours #8310

What happened

When creating a cluster backup or a cluster backup schedule, the "Expires In" field only accepts an hour component of at most two digits. Values such as 120h0m0s or 168h0m0s are rejected with a format error, while 99h0m0s is accepted. The field hint documents the format as HHhMMmSSs without stating any upper bound, so the restriction is not discoverable before the error appears.

Root cause: the frontend format validation for this field caps the hour component at two digits, which implicitly caps the maximum retention at 99 hours.

Expected behavior

The "Expires In" field should accept duration values with an hour component of any reasonable length, so retention periods spanning multiple days (for example 5 days or 7 days) can be configured. Whatever limit does apply should be stated in the field hint and enforced consistently with what the backend accepts.

How to reproduce

1. Open a user cluster and navigate to the Cluster Backups section.
2. Start creating a backup schedule (the same dialog is used for one-off backups).
3. Fill in the required fields, and enter 99h0m0s in "Expires In" — accepted.
4. Change "Expires In" to 120h0m0s or 168h0m0s.
5. The field is marked invalid with a format error and the form cannot be submitted.

Sample payload (reproducer)

Values tested in the "Expires In" field:

• 99h0m0s → accepted
• 120h0m0s → rejected
• 168h0m0s → rejected

Relevant logs / error messages

Inline field error shown in the dialog:

Time must be in the format HHhMMmSSs (e.g., 24h10m10s).

No backend request is issued — the form is blocked client-side.

Environment

• UI Version: 2.31

Current workaround

Set the retention to 99 hours or less, or leave the field empty to fall back to the default retention. Longer retention periods have to be configured outside the dashboard.

Related issues

None