Add an optional, user-set execution timeout to Actions

[cplieger]

What this is for

A ceiling a user can set on how long one Action may run, so a script that is buggy, looping, or waiting on something that never arrives gets stopped and failed instead of running until somebody notices. It is a control for the person writing the Action, not a fix for anything in Komodo.

The root-cause work is separate, in #1564: that closes the channel leaks and the missing cancellation in terminal execution, and stops a killed command's output being discarded. #1564 is the fix, this is a knob. They compose in one specific way: without #1564 a timeout here produces an empty log, and with it you get everything the script printed before the kill, which is what tells you where it stopped.

Related to #1392, whose item 1 asks for an optional timeout on the shell command function. This applies the same shape at the Action layer, with the caveat that an Action is a deliberately long-running case rather than the fast calls that issue has in mind, which is part of why I have not picked a default for you.

Change

ActionConfig.execution_timeout, in seconds, 0 or below meaning no timeout. Passed to the existing CommandOptions::timeout, so the process group is killed and the run is failed, which fires ActionFailed.

Defaults to 0, so upgrading is a no-op: absent Mongo fields deserialize to 0, omitted sync TOML shows no drift, and with timeout = None the select! is exactly the pre-change path. I would suggest 900 as a shipped default, but that is a decision about other people's workloads, so I left it disabled rather than making it for you.

Follows DeploymentConfig.termination_timeout throughout: the attribute triple, i32 seconds, and the UI control is that one with the label and bounds changed.

Known limits

• A kill is SIGKILL to the process group, so the Action's finally never runs and any terminal the script created on a server is not deleted by the script itself. fix: terminal execution channel leaks and lost command output #1564 stops the forwarding task and the response channel leaking on that path, but the PTY still waits for normal cleanup. I am deliberately not proposing SIGTERM escalation: unhandled SIGTERM runs no JS in Deno, so the cleanup would not happen anyway.
• Adding a public field to ActionConfig is semver-major for downstream literal constructors.

Testing

cargo build, cargo test, rustfmt --check on both files, tsc with no new errors in the touched file.

types.ts regenerated with typeshare 1.13.4. I added the resources.json field by hand rather than regenerating, because a full regen also sweeps in unrelated drift (custom_name, tags) that the committed schema is missing; that probably wants its own regen on your side.

Not tested end to end against a running Core, so the kill path is verified from lib/command's own tests plus a local probe rather than from a live Action.