fix(extension): cleanup empty owned tab groups

[jun0315]

Description

Fixes #1627.

When an owned OpenCLI tab is removed, Chrome can leave behind an empty named tab group such as OpenCLI Adapter / OpenCLI Browser. This is visible after ephemeral adapter sessions clean up their temporary tabs.

This PR adds a small owned-tab removal helper that checks whether the tab being removed is the last tab in an
OpenCLI-managed tab group. If so, it calls chrome.tabs.ungroup(tabId) before chrome.tabs.remove(tabId),
preventing Chrome from leaving an empty group behind.

The default grouping behavior is unchanged. OpenCLI still groups owned browser/adapter tabs as before; this only
cleans up the final tab before removal.

Related issue: #1627

Type of Change

• 🐛 Bug fix
• ✨ New feature
• 🌐 New site adapter
• 📝 Documentation
• ♻️ Refactor
• 🔧 CI / build / tooling

Checklist

• I ran the checks relevant to this PR
• I updated tests or docs if needed
• I included output or screenshots when useful

Documentation (if adding/modifying an adapter)

• Added doc page under docs/adapters/ (if new adapter)
• Updated docs/adapters/index.md table (if new adapter)
• Updated sidebar in docs/.vitepress/config.mts (if new adapter)
• Updated README.md / README.zh-CN.md when command discoverability changed
• Used positional args for the command's primary subject unless a named flag is clearly better
• Normalized expected adapter failures to CliError subclasses instead of raw Error

Screenshots / Output

npx vitest run extension/src/background.test.ts
# Test Files  1 passed (1)
# Tests  61 passed (61)

npx vitest run --project extension
# Test Files  2 passed (2)
# Tests  73 passed (73)

cd extension && npm run typecheck
# passed

npm run typecheck
# passed

cd extension && npm run build
# passed

git diff --check
# passed

[jackwener]

Thanks for digging into this @jun0315 — closing this PR after a deeper design review.

The change works as written (and the test additions are solid), but the direction conflicts with how OpenCLI's owned tab groups are designed to work:

The empty OpenCLI Browser / OpenCLI Adapter group is a feature, not a leak.

OpenCLI uses these named groups as persistent automation container markers. When a tab is removed, the group is intentionally left behind as a stable anchor for the next session. The existing reuse path (PR #1541's discoverOwnedContainerFromTabGroup + ensureOwnedContainerTabGroup) finds the existing empty group on the next --site-session ephemeral run and places the new tab back into it — verified just now via a temporary unit test on current main: with an empty OpenCLI Adapter group present and no reusable tab, the next resolveTabId(...) reuses the group and adds the new tab to it (no second group created).

So users see exactly one empty OpenCLI group between sessions, never accumulation. Auto-ungrouping the last tab would actively break that reuse path — Chrome would then create a fresh group with a new ID each session.

If you'd like to take another swing at issue #1627, the right direction would be to verify whether there's a scenario where reuse doesn't trigger (e.g. cross-window edge case, race during teardown), and fix that path — rather than removing the group anchor. Happy to look at a fresh PR going that direction.

Related design: PR #1541 (cross-window owned-container discovery), PR #1566 (regression test for groupId tiebreaker).