Reject IB weekly restart times later than 23:30 UTC

[AlexCatarino]

Description

Interactive Brokers doesn't support weekly restart times later than 23:30 UTC, but --ib-weekly-restart-utc-time accepted any string. An invalid value was only rejected once the deployment reached the brokerage, after the project was compiled and the API call was made.

This adds a TimeParameter click type that enforces the hh:mm:ss format and an optional upper bound, bound to ib-weekly-restart-utc-time through a new map_id_to_types on PromptUserInput. The constraint lives in Python rather than in the modules json because that file is re-downloaded from the CDN daily, so an edit there wouldn't survive.

It covers the three ways a value reaches the config:

• the command line option
• the interactive prompt
• values read from an existing Lean config, which don't go through click, via a new Configuration.validate() called from JsonModule.config_build()

Input without seconds is accepted too, but the value is always normalized to hh:mm:ss, which is what the API schema documents.

$ lean cloud live deploy "My Project" --brokerage "Interactive Brokers" ... --ib-weekly-restart-utc-time 23:50
Error: Invalid value for '--ib-weekly-restart-utc-time': '23:50' is later than the latest supported time of 23:30:00.

Related Issue

N/A

Motivation and Context

Fail fast and locally with a clear message, instead of after a compile and a round trip, and keep a hand-edited lean.json from carrying an unsupported value into a deployment.

Requires Documentation Change

No.

How Has This Been Tested?

• New unit tests for TimeParameter in tests/test_click.py, covering normalization, malformed input and the upper bound.
• New cloud deploy tests asserting rejection of 23:30:01 / 23:50:00 / 23:50 / invalid, and that both 21:00 and 21:00:00 reach api_client.live.start as 21:00:00.
• New local deploy test asserting an unsupported value in lean.json aborts before the runner is called.
• tests/commands/test_live.py, tests/test_click.py, tests/models and tests/commands/cloud/live all pass.
• Manually deployed a live algorithm to QC Cloud with the built wheel.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• All new and existing tests passed.

🤖 Generated with Claude Code