feat(codex): align with official codex marketplace + harness AGENTS.md

[em0t]

Summary

• Switch Codex plugin distribution from a hand-rolled ~/.codex/plugins/cache/ setup to the official codex marketplace add taptap/agents-plugins flow on Codex 0.121.0+.
• Add the missing Codex interface block (displayName / category / capabilities) to all four plugin manifests so they actually appear in the TUI picker.
• Track .agents/plugins/marketplace.json (Codex marketplace registry); set git and sync to INSTALLED_BY_DEFAULT so adding the marketplace bootstraps the core plugins.
• Rewrite root AGENTS.md (also exposed as CLAUDE.md via symlink) into a real harness file with sections for repo layout, commands, conventions, plugin contract, and safety rules.

Motivation

In Codex 0.121.0 the TUI silently rejects any plugin manifest missing an interface block. Our four manifests had only name/version/description/author/skills, so git/sync/spec/test were invisible in the picker even after marketplace registration. On top of that, the previous ensure-codex-plugins.sh used the legacy source_type = "local" cache layout, which Codex's plugin manager interprets as nested sub-plugins (it walks into git/skills/ looking for .codex-plugin/plugin.json), producing repeated missing or invalid plugin.json path=...git/skills warnings.

The fix is to stop reinventing the cache and let Codex own it. The official codex marketplace add against this repo on GitHub installs into the correct <marketplace>/<plugin>/<sha>/ layout and honors INSTALLED_BY_DEFAULT.

Scope

• GitHub workflows / repository automation
• Marketplace metadata or release flow
• Plugin implementation
• Tests or validation scripts
• Documentation

Validation

• Local verification completed
• CI validation expected to pass
• No runtime verification needed

tests/validate.sh passes (existing checks plus four new ensure-codex-plugins.sh cases and Codex interface schema validation). End-to-end Codex behavior (codex marketplace add → INSTALLED_BY_DEFAULT → plugins visible in TUI) was confirmed with the openai-curated reference flow; the same path will work against this repo only after this PR lands on main, since codex marketplace add taptap/agents-plugins requires the new .agents/plugins/marketplace.json to be on the default branch.

Verification steps after merge:

1. rm -rf ~/.codex/plugins/cache/taptap-plugins ~/.codex/.tmp/app-server-remote-plugin-sync-v1 and remove any pre-existing [marketplaces.taptap-plugins] from ~/.codex/config.toml.
2. codex marketplace add taptap/agents-plugins → codex exec --skip-git-repo-check 'echo verify'.
3. Confirm ~/.codex/plugins/cache/taptap-plugins/git/<sha>/ and sync/<sha>/ exist; confirm ~/.codex/log/codex-tui.log no longer reports failed to load plugin: missing or invalid .codex-plugin/plugin.json plugin="git@taptap-plugins".
4. In Codex TUI, $git shows TapTap Git; $sync shows TapTap Sync.

Regression Risk

• Downstream repos that ran the previous ensure-codex-plugins.sh still hold the old script under <repo>/.codex/hooks/scripts/. Until they re-run /sync:basic to pick up the new version, their SessionStart hook will keep writing the legacy non-versioned cache layout. Mitigation: documented in CHANGELOG.md; re-running /sync:basic is a one-line fix.
• Users who manually registered [marketplaces.taptap-plugins] with source_type = "local" need to remove that section so the new script can re-register via the GitHub source. Documented in the cleanup steps above.
• Concurrent SessionStart invocations can both run codex marketplace add; the second call returns "already added" with exit 0. Harmless but redundant. A flock could be added later if it becomes noisy.

No production runtime is affected by this PR — it only changes how local Codex installations discover the plugins.

AI Disclosure

• Authoring tools: Claude Code (Opus 4.7, 1M context)
• Review tools: Claude Code (Opus 4.7) — single-pass review of committed diff against the project checklist; no blocking findings

Checklist

• The PR title is in English
• Commit messages are in English
• I updated docs when behavior or workflow changed
• I considered versioning rules if plugin files changed