[CloudCorpRecords]

What the limit is

The Cloud create-deployment API rejects expirations more than 5 days in the future (HTTP 400 InvalidExpiresAt: expiresAt cannot be more than 5 days in the future), as documented in #196.

What changed

The --expiration help example for convex deployment create (and the expiration parse-error message) used "in 7 days" as the relative example, which the API rejects. This PR changes both examples to "in 1 day", comfortably inside the observed five-day maximum, as proposed in the issue.

Files:

• src/cli/deploymentCreate.ts — --expiration <value> option help text
• src/cli/lib/expiration.ts — PARSE_ERROR_MESSAGE relative-format example

Help text only; parseExpiration / validateExpiration behavior is unchanged. No client-side validation rule was added, since limits may differ by deployment type or account (per the issue's proposal).

Evidence

• Reproduced the exact strings in upstream/main: deploymentCreate.ts:81 and expiration.ts:13 both said "in 7 days" before this change.
• Verified the new branch head's tree SHA matches the locally built tree, and git diff on the two files shows only the example swap.
• No existing tests assert on these strings (only src/cli/network_test.ts exists under src/cli/, unrelated), so nothing to update.

Honest limits

• I did not replay the API call or create a Cloud target to re-verify the 5-day ceiling; the limit is taken from the issue's recorded evidence.
• I could not run the full npm test suite in this environment (integration/e2e coverage lives outside this repo anyway per CONTRIBUTING.md), but this change touches only help strings and cannot affect runtime behavior.

Fixes #196.