smoke: wait for pi-extensions deploy completion, not just keybindings

The entrypoint-deploy wait loop gated only on keybindings.json (written by
pi-toolkit, before pi-extensions), so the *.ts >= 4 assertion could sample
mid-deploy under parallel build load. v1.16.2 run 370: smoke-with-pi saw <4
while omos-with-pi/pi-only (same pi-extensions 357fcc6) saw 8, skipping
build-variant-with-pi. Now wait for the last-deployed artifact (mempalace.ts
bridge) AND a settled extension count (>=4), up to 45s. Test-only; no image
change, so no re-tag needed.

CHANGELOG.md

@@ -8,7 +8,19 @@ Tags follow `v{opencode_version}[letter]` — bare tag for the first build on a
 
 ## Unreleased
 
-_(no changes since v1.16.2)_
+### Fixed: smoke-test pi-extensions readiness race (test-only, no image change)
+
+`scripts/smoke-test.sh`'s entrypoint-deploy wait loop gated only on
+`keybindings.json` (written by pi-toolkit, which runs *before* pi-extensions),
+so the `~/.pi/agent/extensions/*.ts ≥ 4` assertion could sample mid-deploy and
+see fewer than 4 files under parallel build load. Observed on v1.16.2 run 370:
+`smoke-with-pi` saw `<4` while `smoke-omos-with-pi` / `smoke-pi-only` (identical
+pi-extensions `357fcc6`) both saw 8, skipping `build-variant-with-pi`. The wait
+loop now blocks until the *last*-deployed artifact (the `mempalace.ts` bridge
+symlink) exists **and** the extension count has settled ≥ 4 (up to 45s). Affects
+only when smoke samples the container — image bytes are unchanged, so this does
+not warrant a new tag; it lands in the next release and is exercised by
+`validate.yml` on this push.
 
 ## v1.16.2 — 2026-06-08