fix(harness): correct pi config paths, provider schema, and bridge layout

[nhuelstng]

Summary

Structural fixes on top of #73, found via review and verified live against a real pi 0.80.6 install and the real SKAINET gateway. Each item below was reproduced concretely, not just inferred from docs.

• Bridge extension hang (severe). .pi/extensions/omac-bridge/index.ts (subdirectory + index.ts) reproducibly hung pi indefinitely on every launch. Confirmed by loading the identical file content both ways: flat file loads instantly, subdirectory form hangs with zero output even with --verbose. Pi's docs only document flat-file auto-discovery under .pi/extensions/*.ts. Fixed by flattening to .pi/extensions/omac-bridge.ts. Also hardened before_agent_start to return {systemPrompt} per the documented hook contract, in addition to the existing messages.unshift, since it wasn't independently confirmed which application mechanism pi's runtime actually uses.
• UserConfigHome was .pi; pi's real config home is ~/.pi/agent. Confirmed from pi's own docs and a live install: models.json, sessions/, skills/, and extensions/ all live under ~/.pi/agent/, not directly under ~/.pi/. This silently broke GlobalSkillsDir() — omac's auto-provisioned built-in skill was landing at ~/.pi/skills, which pi's own loader never reads — and GlobalBridgeDir(). The existing piSessionsRoot() had already worked around this by manually appending "agent", which is the tell that this was an oversight, not a deliberate choice. Fixed UserConfigHome to .pi/agent and removed the now-redundant manual append in piSessionsRoot().
• Missing PI_CODING_AGENT_DIR env override — pi documents this as its config-home override; added as HomeEnv.
• e2e provider config didn't match pi's real schema, and was missing a required flag. ProviderSetup wrote ~/.pi/agent/auth.json + settings.json, a schema pi's provider loader doesn't recognize. RunArgs also omitted --provider (pi defaults to --provider google without it). Live-tested: this exact combination hangs indefinitely against the real gateway, while the same --model flag with zero provider config fails fast and cleanly instead — confirming the hang is tied to the unrecognized config being present. Replaced with pi's actual documented custom-provider schema (~/.pi/agent/models.json, a providers map) plus --provider model in RunArgs; verified live (real 200s, real completions) against SKAINET.
• Fabricated e2e version pin. @earendil-works/pi-coding-agent@2026.7.7 doesn't exist on npm (checked via npm view ... versions — only semver releases up to 0.80.6 are published) and would 404 in CI. Pinned to the real latest, 0.80.6.
• .github/workflows/e2e.yml never got pi added to matrix.harness. Added.
• Also dropped the unconfirmed ~/.cache/pi SandboxDirs entry — not observed in a live install (pi's caches nest under ~/.pi/agent/{git,npm}).

Verification

• go build, go vet, staticcheck, go test ./... (incl. -race) all clean.
• Live, outside any test harness: omac start pi under the real bwrap sandbox against SKAINET — built-in skill correctly provisioned to ~/.pi/agent/skills, real model response received.
• go test -tags=e2e -run TestE2EEchoRest/pi and TestE2ESecurityAudit/pi against the live SKAINET gateway: both pass, every sandbox-boundary assertion holds (secrets, fs read/write, network, sidecar, env passthrough).

Test plan

• Unit tests pass (go test ./...)
• TestE2EEchoRest/pi passes against live SKAINET
• TestE2ESecurityAudit/pi passes against live SKAINET
• Manual omac start pi verified end-to-end under the real sandbox

🤖 Generated with Claude Code