fix(weather-demo): teach pick_log_container the proxy-sidecar container name

[huang195]

Summary

pick_log_container in deploy_and_verify_advanced.sh only knew two AuthBridge sidecar container names — envoy-proxy (envoy-sidecar mode) and authbridge. After #411 + kagenti-operator#361 the cluster default became proxy-sidecar with container name authbridge-proxy, which the script doesn't recognize, so every CI run dies on the first pick_log_container call.

Caught on kagenti#1592's Deploy & Test lane:

ERROR: pod weather-tool-advanced-... has neither envoy-proxy
       nor authbridge container (mcp
       authbridge-proxy)

The pod actually had mcp + authbridge-proxy — the webhook injected fine and the demo flow was healthy. The script just couldn't tell which container to read logs from. The error message itself was misleading (the multi-line container list got split across two log lines, so casual readers saw "(mcp" and assumed no sidecar was injected).

Fix

The two recognized names in pick_log_container are now the only two the operator actually produces today:

• authbridge-proxy — proxy-sidecar mode, the post-feat: Add MCP parser plugin and body access infrastructure #361 cluster default. From AuthBridgeProxyContainerName in kagenti-operator/internal/webhook/injector/constants.go:34.
• envoy-proxy — envoy-sidecar mode. From EnvoyProxyContainerName in kagenti-operator/internal/webhook/injector/container_builder.go:34.

The bare authbridge name from the pre-#361 combinedSidecar feature gate is not kept as a fallback. That gate (and its AuthBridgeContainerName = "authbridge" constant) was removed in #361, and deploy_and_verify_advanced.sh already requires the post-#361 agentruntimes.agent.kagenti.dev CRD a few lines above, so there's no pre-#361 path to keep working.

Also reformat the diagnostic message — wrap $names in $(echo $names) so the pod's container list renders on a single line, making the error read expected one of …; got: mcp authbridge-proxy instead of visually truncating.

Test plan

• bash -n on the script
• grep -r for similar restricted name lists across other shell / Python helpers — none found
• Cross-checked against the operator's container-name constants — only the two names this PR keeps are still produced
• Re-run kagenti#1592's Deploy & Test once this lands and the e2e clone of extensions main picks up the fix

Assisted-By: Claude (Anthropic AI) noreply@anthropic.com

[pdettori]

Clean, minimal fix that updates pick_log_container() to recognize the post-#361 proxy-sidecar container name (authbridge-proxy). The fallthrough loop is cleaner than the old if-elif, the inline comments citing operator constants are helpful, and the $(echo $names) fix for single-line error output is a nice touch. One nit: the commit message body is stale — it describes a three-name loop that was trimmed to two before push.

Areas reviewed: Shell, PR format, commit conventions, security
Commits: 1 commit, signed-off: yes
CI status: all 17 checks passing

[pdettori]

nit: The commit message body says the loop covers three names (authbridge-proxy / envoy-proxy / authbridge) and that "the legacy combined name is kept for older clusters / replays" — but the code only loops over two (authbridge-proxy envoy-proxy), matching the PR description's deliberate exclusion of bare authbridge. The commit message appears to be from an earlier iteration. Not blocking since the code + PR description are correct, but worth a force-push to fix if convenient.