Switch container builds to manual-only workflow dispatch

Shared Dagger helpers (src/blumeops/) affect all Dagger-built containers,
making path-based auto-triggers unreliable. All builds now go through
`mise run container-build-and-release <name>`.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

docs/changelog.d/+container-manual-builds.infra.md

@@ -0,0 +1 @@
+Container builds are now manual-only via `mise run container-build-and-release`. Removed auto-trigger on push to main — shared Dagger helpers made path-based detection unreliable.

docs/explanation/agent-change-process.md

@@ -58,7 +58,7 @@ A change with enough complexity or risk that a human should review it, but not s
    - **Workflows:** point workflow triggers at the branch if needed
 8. After user review and successful deployment, the user merges the PR
 9. **After merge:** reset ArgoCD revisions back to main, re-sync
-10. **If the PR changed `containers/`:** the merge triggers a rebuild from main automatically. Once it completes, commit a C0 updating the manifest to the new `[main]`-tagged image (see [[build-container-image#Squash-merge and container tags]])
+10. **If the PR changed `containers/`:** trigger a rebuild with `mise run container-build-and-release <name>`. Once it completes, commit a C0 updating the manifest to the new `[main]`-tagged image (see [[build-container-image#Squash-merge and container tags]])
 
 ### Upgrading to C2
 
@@ -235,8 +235,8 @@ When starting a new session to continue C2 work:
 Mikado resets apply to branch code, not build artifacts. Container images in the registry are independent of branch lifecycle:
 
 - **Registry images** are build outputs cached in zot — tagged with commit SHAs, so each build is unique and traceable
-- **Squash-merge orphans:** Images built during PR development reference branch SHAs that won't exist on main after merge. After merge, a rebuild triggers automatically; commit a C0 to update manifests to the new `[main]`-tagged image. Use `mise run container-list <name>` to find it
-- **Automatic builds** trigger when container changes merge to main. Use `mise run container-build-and-release` for manual dispatch
+- **Squash-merge orphans:** Images built during PR development reference branch SHAs that won't exist on main after merge. After merge, trigger a rebuild with `mise run container-build-and-release <name>` and commit a C0 to update manifests to the new `[main]`-tagged image. Use `mise run container-list <name>` to find it
+- **All builds are manual** — use `mise run container-build-and-release <name>` to dispatch
 - **If a build succeeds but deployment fails**, the image is fine; the problem is elsewhere. Document what you learned and try again
 - **If a build fails in CI**, no image is pushed. Fix the nix/dockerfile and re-merge or re-dispatch
 

docs/how-to/dagger/upgrade-dagger.md

@@ -43,7 +43,7 @@ The runner job image contains the Dagger CLI binary. Upgrading it first means th
 
 2. Update `service-versions.yaml` — bump `current-version` and `last-reviewed` for `runner-job-image`.
 
-3. Commit and push to main. The `Build Container` workflow triggers automatically (it watches `containers/**`), building and publishing the new runner-job-image with the updated Dagger CLI.
+3. Commit and push to main. Trigger a build with `mise run container-build-and-release runner-job-image`.
 
 4. Verify the build succeeds — check the workflow run on Forgejo. Note the image tag from the build output (format: `v<version>-<sha>`).
 

docs/how-to/deployment/build-container-image.md

@@ -57,9 +57,9 @@ nix-build containers/<name>/default.nix -o result
 
 ## 3. Release
 
-Container builds trigger automatically when changes to `containers/<name>/` are merged to `main`. Both workflows fire and each skips if the relevant build file is absent.
+Container builds are triggered manually. Shared Dagger helpers (`src/blumeops/`) affect all Dagger-built containers, making path-based auto-triggers unreliable.
 
-To trigger a manual build (e.g. from a branch or to rebuild at a specific commit):
+To trigger a build:
 
 ```bash
 mise run container-build-and-release <name>
@@ -106,7 +106,7 @@ Container image tags include the git commit SHA they were built from (e.g. `v3.9
 
 **The rule:** Production manifests must reference images built from a commit on main. After merging a PR that changed `containers/<name>/`:
 
-1. The merge to main automatically triggers a rebuild (the `build-container.yaml` / `build-container-nix.yaml` workflows fire on pushes to `main` that touch `containers/**`)
+1. Trigger a rebuild: `mise run container-build-and-release <name>`
 2. Wait for the workflow to complete — verify with `mise run runner-logs` (find the run, check status)
 3. Find the new main-SHA tag:
    ```bash

docs/how-to/zot/adopt-commit-based-container-tags.md

@@ -25,12 +25,11 @@ Currently, container builds trigger on git tags matching `<container>-vX.Y.Z`. T
 
 ### Triggers
 
-1. **Merged changes to main** — any push to `main` that modifies files under `containers/<name>/` triggers builds for that container
-2. **Manual workflow dispatch** — for ad-hoc builds. Accepts two inputs:
-   - `container` (required) — which container to build
-   - `ref` (optional, string) — the source commit SHA to build, defaulting to `GITHUB_SHA`
+All container builds are triggered manually via `mise run container-build-and-release <name>` (which dispatches the workflow). Accepts two inputs:
+- `container` (required) — which container to build
+- `ref` (optional, string) — the source commit SHA to build, defaulting to `GITHUB_SHA`
 
-Both the Dockerfile and Nix workflows fire for each trigger, each bailing out if the container lacks the relevant build file (same as today).
+The workflow classifies the container by build type and routes to the correct runner.
 
 ### Version Source