feat(ci): run build on push to main — build (agentcore) has not verified main since 2026-06-04

## Problem

`build (agentcore)` — the gate that runs the entire test suite (agent pytest, cdk jest, cli jest) — **never runs against `main`**. `.github/workflows/build.yml` triggers on:

```yaml
on:
pull_request: {}
merge_group: {}
workflow_dispatch:
```

No `push:`. Consequence: the last time the suite ran on `main` was **2026-06-04** (`e3abe925c`), and that was a manual `workflow_dispatch`. Every `main` run in the history is a manual dispatch; there has never been an automatic one.

In that window `main` received, among much else, MicroVM P1 (#645 / `f3cfb4e3b`, Aug 6), MicroVM P2 (#733 / `4d53a73b0`, Aug 28), the standalone Agent Registry (#779), and the Bedrock geo refactor (#764). None was ever verified against `main` as it actually exists post-merge.

## Why the existing gates don't cover this

- **`pull_request`** tests a PR's *merge preview* — main-at-that-moment plus the branch. It says nothing about main after the merge lands.
- **`merge_group`** tests the *queued combination*. Good, but it's the last look, and it doesn't re-verify after the fact.
- Nothing at all runs on the resulting commit.

So a defect that only manifests post-merge, intermittently, or through interaction with a later merge has **no backstop whatsoever**. The repo has no way to answer "is `main` green right now?" other than a human manually dispatching the workflow — which is exactly what had to be done to answer that question today ([33510225606](https://github.com/aws-samples/sample-autonomous-cloud-coding-agents/actions/runs/33510225606); it passed: agent 1755, cdk 4322, cli 768).

## Evidence this is a live gap, not theoretical

- #841 (test_server.py thread leak) is a **race** that is latent on `main` today. Two different tests failed on two runs of an unrelated CLI-only PR (#680) while `main` itself happened to pass. Without a scheduled/push run on `main`, a flake like this is only ever seen as "someone else's PR is red," which is precisely how it got misattributed.
- #729 (`security:sast` fails on main) was found by @scottschreckengaust **locally**, via a red pre-push hook on an unrelated branch — not by CI. His write-up names the same asymmetry class as #721: the local gate is stricter than the merge gate.

Two independent instances of "main was broken/fragile and CI was not the thing that noticed."

## Proposed fix

```yaml
on:
pull_request: {}
merge_group: {}
push:
branches: [main]
workflow_dispatch:
...
```

Considerations worth deciding explicitly:

- **Cost.** The suite runs ~13-15 min. At current merge cadence this is a modest add, and `merge_group` already pays a similar cost per merge. If that's still too much, a `schedule:` (nightly) is a weaker but non-zero alternative — it bounds "how long can main stay broken without anyone knowing" to 24h instead of unbounded.
- **Notification.** A red `main` run needs to reach someone. A push-triggered failure that nobody is subscribed to reproduces the current situation with extra steps.
- **Don't make it a required check on `main`** — it reports after the merge, so it cannot gate one.

## Checklist

- [ ] `push: branches: [main]` added to `build.yml`
- [ ] Failure on `main` notifies a human (issue auto-file, Slack, or CODEOWNERS ping) — decide the channel
- [ ] Confirm the `deploy` job stays gated and does not fire on push
- [ ] Backfill: one dispatch after this lands, to establish a known-good baseline commit

Start with .github/workflows/build.yml and inspect its existing pull_request, merge_group, workflow_dispatch, build, and deploy configuration. Add the main push trigger, verify that deploy remains gated and does not run on pushes, then dispatch one run after the change to establish a known-good baseline; decide and implement the documented human notification channel for failures.

Written by the indexing model from the issue text.