Add CLI helpers for managing schedules

[bradhe]

This PR introduces CLI helpers for managing schedules.

╭─bradhe@Mac ~/Development/tower/tower-cli ‹feature/tow-512-add-new-schedule-editor-to-tower-cli●› 
╰─$ cargo run -- schedules create --app=my-test-app --environment=default --cron="*/15 * * * *"
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/tower schedules create --app=my-test-app --environment=default '--cron=*/15 * * * *'`
✔ Creating schedule Done!
Success! Schedule created with ID: 40bb2360-bb6e-4c90-9780-dc48a498d75c
╭─bradhe@Mac ~/Development/tower/tower-cli ‹feature/tow-512-add-new-schedule-editor-to-tower-cli●› 
╰─$ cargo run -- schedules list                                                                
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.08s
     Running `target/debug/tower schedules list`
 ID                                    App          Environment  Cron         
------------------------------------------------------------------------------
 40bb2360-bb6e-4c90-9780-dc48a498d75c  my-test-app  default      */15 * * * * 
 ╭─bradhe@Mac ~/Development/tower/tower-cli ‹feature/tow-512-add-new-schedule-editor-to-tower-cli●› 
╰─$ cargo run -- schedules delete 40bb2360-bb6e-4c90-9780-dc48a498d75c
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/tower schedules delete 40bb2360-bb6e-4c90-9780-dc48a498d75c`
✔ Deleting schedule Done!
Success! Schedule 40bb2360-bb6e-4c90-9780-dc48a498d75c deleted

[Copilot]

Pull Request Overview

This PR adds comprehensive CLI functionality for managing schedules in Tower applications. The implementation provides CRUD operations for schedules with support for cron expressions and runtime parameters.

Key changes include:

• New CLI module with commands for creating, listing, updating, and deleting schedules
• API integration functions for all schedule operations with proper error handling
• Command-line argument parsing for schedule parameters and filters

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
crates/tower-cmd/src/schedules.rs	Implements CLI commands and handlers for schedule management operations
crates/tower-cmd/src/lib.rs	Integrates the schedules module into the main CLI application
crates/tower-cmd/src/api.rs	Adds API client functions for schedule operations with response handling

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The update command requires a cron parameter but doesn't allow updating other fields independently. Consider making cron optional in updates to allow partial updates of schedule properties.

Suggested change

	if cron.is_none() {
	output::die("You must specify a cron string (--cron) for this schedule");
	}
	// Allow partial updates: cron is optional.

[socksy]

I suppose you might wanna update the parameters instead of the cron.

[socksy]

I wonder if we may want to change that in the future... It is common in CLJ world to have env variable config be able to autodetect numbers and keywords etc and coerce them, surely something similar must exist in the Python world? In which case I'd be annoyed I had to specify them as strings in the JSON (even though behind the scenes we'd just coerce them into strings before passing them in as env variables anyhow).

[socksy]

👍 I really like this naming pattern of having the outer, side effectful user interaction be do_something that then calls the pure some_the_thing inside. This makes it easier to adapt for the MCP server, where I discovered that e.g. getting exposed to a spinner is a very unfortunate thing to go to an LLM.

[socksy]

I'm not sure it should be required as an argument here. I guess we're already doing this elsewhere so it makes sense to continue in this PR, but I would expect to have it go to the default environment, or to be able to set it in other ways than the CLI arg (env var, config file)

[bradhe]

Ah, yes, good point--we use "default" everywhere else. I'll update this.