feat(plugin): use SDK v2

[eXamadeus]

What does this PR do?

Fixes #7641
Fixes #7147

While investigating this for my own plugin, I arrived at a similar direction as #7639. I'm wasn't sure why several of the changes in that PR were made, and it also introduces breaking changes for plugin developers. So I decided to roll a new PR out.

This PR takes a different approach with a minimal set of updates to enable the plugin system to use the v2 client. It also exposes the v2 client as clientNext via PluginInput.

Important

Providing two clients avoids the backwards-compatibility issue. Keeping the original client intact allows clientNext to adopt SDK v2 without forcing developers to migrate immediately. Plugin authors can move at their own pace, and we can defer any breaking changes until the next major release.

How did you verify your code works?

• Type checks
• Local testing with my plugins

[github-actions]

Hey! Your PR title feat(plugin system): use SDK v2 doesn't follow conventional commit format.

Please update it to start with one of:

• feat: or feat(scope): new feature
• fix: or fix(scope): bug fix
• docs: or docs(scope): documentation changes
• chore: or chore(scope): maintenance tasks
• refactor: or refactor(scope): code refactoring
• test: or test(scope): adding or updating tests

Where scope is the package name (e.g., app, desktop, opencode).

See CONTRIBUTING.md for details.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

Based on my search, I found a related PR:

Related/Potential Duplicate:

• PR feat(plugin)!: migrate plugin system to SDK v2 #7639: feat(plugin)!: migrate plugin system to SDK v2
  • feat(plugin)!: migrate plugin system to SDK v2 #7639

Why it's related: This PR is explicitly mentioned in your description. PR #7639 addresses the same issue (#7641) and takes a similar approach to migrate the plugin system to SDK v2. However, your PR (#8380) takes a different, less breaking approach by exposing both the v1 client and v2 clientNext to maintain backwards compatibility, whereas #7639 introduces breaking changes for plugin developers.

Recommendation: Consider whether both PRs are needed or if one approach should supersede the other. If #7639 is still open, you may want to coordinate with its author or potentially mark one as a duplicate depending on which approach the maintainers prefer.

[eXamadeus]

The Permission type was technically a lie. There is no analog in SDK v2, so rolled one that is correct (which is already a common pattern here).