Add setting for MUX: choose what to do with coder workspace after "Archive chat"

[truebest]

Description:
Please add a setting that lets the user decide what should happen to the coder workspace after clicking “Archive chat” in MUX.

Suggested options:

• Keep workspace - don’t change anything, just archive the chat.
• Stop workspace - that we currently have.
• Delete workspace - completely remove the workspace.
• Custom action (optional) — allow users to run a custom script/command.

Motivation:
Right now, archiving a chat automatically stops the coder workspace, but users can’t choose another action. Sometimes stopping isn’t enough: you may want to keep the workspace running (e.g., for background jobs), or delete it immediately to save resources, or run a custom cleanup script. Making this behavior configurable would help teams avoid accidental loss, wasted resources, or manual re-starts.

My current use case:
I’m personally using Bazel in my project, and it has one major limitation: there is a single Bazel cache server, which means you can’t run multiple Bazel builds from different source folders at the same time. Because of that, I have to use a separate container/workspace for each chat in MUX.

Once a chat is done and I’ve pushed the changes to a remote, sometimes I’d prefer to keep the workspace running, since all dependencies are already downloaded and it could be reused for another task. But this also creates extra complexity: with N workspaces, I have to manually pick a free one to continue work.

The ideal scenario for me would be:

• While I’m actively using/working in a chat, I want the workspace linked to that chat.
• When I close/archive the chat, I’m typically ready to delete the workspace and start fresh for the next one.
• But sometimes, I may want to keep it running for a while or trigger a specific action.

Letting users pick the post-archive action for the workspace would make life much easier for anyone working with Bazel or other cache-sensitive tools.

Use case:

• User archives a chat and can pick the workspace fate: keep running, stop, delete, or trigger a script.
• No more confusion about whether background jobs are killed, data is preserved, or resources are freed.
• Makes workflow safer and clearer for all types of users.

[truebest]

That's all we have:

By default, archiving a New (mux-created) Coder-backed workspace will also stop the underlying Coder workspace, and unarchiving will attempt to start it again. This does not apply when using an Existing Coder workspace. To disable this behavior, set stopCoderWorkspaceOnArchive to false in ~/.mux/config.json.