fix(tui): deduplicate plugin targets

[kitlangton]

Why

A combined plugin can reach the TUI through both local-directory discovery and the server plugin inventory. When loading fails, both equivalent targets were resolved independently and displayed as duplicate failure rows, making one failure look like two plugins.

What Changes

Sources	Before	After
Local discovery + server inventory resolve to the same local path	Resolve twice, report two failures	Resolve once, report one failure
Later configured target matches an earlier target	Both targets retained	Later target options win without changing list position
Targets resolve to different paths or package names	Both retained	Both retained

Targets are canonicalized with the existing local source resolver before plugin loading. Deduplication retains the final target definition so explicit configuration keeps precedence over discovered and server-provided defaults.

Demo

The recordings use the same isolated combined plugin fixture. Its TUI entrypoint intentionally throws Fixture plugin failed.

Before: one failed target appears twice.

dedupe-before.mp4

After: the equivalent sources produce one failed target.

dedupe-after.mp4

OpenCode Drive 2.1.0 could not launch current V2 for this capture because of opencode-drive#87. These matched recordings use a real PTY via Terminal Control instead.

Scope

This PR deduplicates TUI plugin resolution targets only. It does not change server plugin inventory or successful plugin registration by plugin ID.

Verification

cd packages/tui
bun test test/plugin-discovery.test.ts
bun typecheck

cd ../..
bun run check

• Focused regression: 2 passed
• TUI typecheck: passed
• Repository lint and typecheck: passed
• Real TUI fixture: duplicate failed rows reduced from two to one

The complete TUI suite also ran: 1,076 passed and 5 existing environment-sensitive lifecycle tests failed because they discovered the globally installed personal kit.codex-limits.tui plugin inside fixtures.