chore(agent-zero): bump upstream to v2.11

[github-actions]

Closing as superseded — this is the automated twin of #2789 (same template), filed AFTER the v2.11 content already landed the correct way:

• Fork merge: PMOVES-Agent-Zero#19 (2-parent merge of agent0ai@v2.11, 71 commits, kept the TensorZero patch)
• Gitlink promotion: chore(submodules): promote PMOVES-Agent-Zero to 27957f1 (upstream v2.11) #2850 (80371121 -> 27957f11), then chore(submodules): promote PMOVES-Agent-Zero to 5c280a9 (MCP arg filter) #2852 (-> 5c280a99 MCP arg filter)
• Live-validated on SPARK: image rebuilt from the hardened branch, a0-connector.v1 | 5c280a9, /sessions round-trip OK

The approach in this PR remains architecturally wrong for this repo: AGENT_ZERO_REF clones the hardened BRANCH by design (Dockerfile comment: "must stay the hardened BRANCH") — a tag REF builds raw upstream and silently drops all PMOVES hardening.

Route to the bump-bot lane: the generator's detection expects a Dockerfile REF bump to consider a version merged; it should instead recognize the fork-merge + gitlink pattern (or check the image's agent_zero_version), or it will keep regenerating this PR for every release.

💘 Generated with Crush

[github-actions]

CI Failure Analysis

The following checks failed:

• CI did not complete or timed out

Likely Cause

The Dockerfile is currently pointed at the upstream tag, but the PMOVES fork has not been synced yet. This is expected behaviour.

Next Steps

1. Complete the fork sync process (see PR description)
2. Update AGENT_ZERO_REF to point to the synced fork branch
3. Push the update — CI will re-run automatically

[POWERFULMOVES]

Retracting my own retraction — the fork has no tags

I previously reviewed this change (as #2789), flagged the AGENT_ZERO_REF rewrite, then retracted after reading the body as a deliberate transitional handoff. That retraction was wrong. Measured on origin/main at 6890a0f03, 2026-08-31:

$ git ls-remote --tags https://github.com/POWERFULMOVES/PMOVES-Agent-Zero.git | wc -l
0

$ git ls-remote --heads .../PMOVES-Agent-Zero.git | grep Edition-Hardened
5c280a994794c891b9964ef19e9a64c3d45c03ee  refs/heads/PMOVES.AI-Edition-Hardened

$ git ls-tree origin/main PMOVES-Agent-Zero
160000 commit 5c280a994794c891b9964ef19e9a64c3d45c03ee  PMOVES-Agent-Zero

Three consequences, in order of severity:

1. The new ref cannot resolve. AGENT_ZERO_REPO defaults to the fork, and the fork carries zero tags. The comment three lines above this very diff already predicts the outcome:

"The fork also carries no tags at all, so a tag here fails the clone outright rather than silently shipping an unhardened image."

AGENT_ZERO_REF=v2.11 is exactly that tag. The clone fails outright.

2. The value being replaced is already correct. PMOVES.AI-Edition-Hardened resolves to 5c280a9 — byte-identical to the gitlink main already carries. This is not a stale ref being advanced; it is a live, in-sync ref being replaced with a broken one.

3. The transitional argument has expired. The gitlink half landed via #2850 (27957f1, upstream v2.11) and #2852 (5c280a9, MCP arg filter). Whatever handoff state this PR was staging for, main is now past v2.11. Pinning AGENT_ZERO_REF=v2.11 would also pin behind the merged gitlink.

The AGENT_ZERO_UPSTREAM_VERSION=v2.10 -> v2.11 half of the hunk is accurate and harmless — that ARG is documentation of which upstream the overlay tracks. Only the AGENT_ZERO_REF line is the problem.

Suggested shape: keep AGENT_ZERO_UPSTREAM_VERSION=v2.11, leave AGENT_ZERO_REF=PMOVES.AI-Edition-Hardened untouched. That yields a correct, buildable statement of the same fact.

Not verified here: I did not run a build. The claim is about ref resolution, which ls-remote settles without one.