[codex] Reuse parsed plugin skills during session startup

[xl-openai]

Summary

• Preserve raw plugin skill-root snapshots in the matching loaded-plugin cache entry, keyed by the effective plugin root identity including namespace.
• Pass those snapshots through SkillsLoadInput as an optional preload, so session startup reuses plugin parsing while ordinary skill loads pass None.
• Keep plugin skill loading cohesive: the existing loaders accept the optional snapshots directly, and uncached or marketplace-detail paths do not create a cache.

Why

Plugin discovery already parses plugin skills to determine available capabilities. Cold session startup then scanned and parsed the same roots again while building the skills snapshot.

This solves the same duplicate-work problem as #28623 while keeping ownership narrow: PluginsManager creates and owns PluginSkillSnapshots only for its loaded-plugin cache entry; SkillsService consumes an optional clone. Entry replacement or clearing naturally drops the snapshots, with no separate generation, capacity policy, or watcher coupling.

Validation

• cargo clippy -p codex-core-skills --all-targets -- -D warnings
• just test -p codex-core-plugins skills_service_reuses_skills_parsed_during_plugin_load
• just test -p codex-core-skills namespaces_plugin_skills_using_provided_namespace
• just fmt

[mzeng-openai]

Could we invalidate these snapshots when SkillsService is cleared? The app-server watcher only clears the skills cache, so a plugin SKILL.md edit can still reuse stale metadata on the next turn after skills/changed fires.

[xl-openai]

Good catch. I took a closer look, and I think the issue is actually that plugin-owned skill roots shouldn’t be registered with SkillsWatcher in the first place. Plugin install/update/uninstall owns invalidating plugin state, including these snapshots. I pushed ce979d1 to exclude plugin roots from watcher registration rather than coupling SkillsService cache clears back into PluginsManager. Thanks for flagging this!