[FEATURE]: Let plugins filter model-visible Skills per session

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

We are building a third-party plugin called hev that organizes OpenCode's already-discovered native Skills into user-defined Environments and binds one Environment to each OpenCode session. The plugin does not install, parse, or load Skill bodies. It only decides which native Skills the model should automatically see for the current session.

Today, plugins can contribute Skill sources, but they cannot filter the resolved, model-visible Skill catalog at runtime. Static agent permissions cannot represent a plugin-owned session-to-Environment binding. Post-processing the system prompt would also be fragile because the model-facing skill tool could bypass it.

Could the V2 plugin Skill API provide a session-scoped visibility hook, conceptually like this?

ctx.skill.visibility(async (event) => {
  const allowed = await environmentSkills(event.sessionID)
  event.skills = event.skills.filter((skill) => allowed.has(skill.name))
})

The hook would receive the current session ID, agent ID, and resolved Skill list. Its result would be used consistently by both Skill guidance (<available_skills>) and the model-facing skill tool. This extension point could also support other plugins that manage Skill profiles, workspaces, or context budgets.

Compatibility boundaries:

• When no visibility hook is registered, current behavior remains unchanged.
• OpenCode continues to own native Skill discovery, permissions, and body loading.
• The hook only controls model-visible Skills; explicit user invocation such as /skill-name remains available.
• Plugins own their session policy; no persisted OpenCode setting or HTTP API is required.
• No hev-specific concept needs to enter OpenCode core.

This is related to #11972 and #33336, but distinct: those cover static frontmatter or agent-permission behavior, while this request enables dynamic, plugin-owned, per-session catalog selection.

Would this plugin extension point fit the project direction, and should an implementation currently target dev or v2? I would be happy to contribute it after design approval.