feat(browser): add strict Chrome Tab Group background carrier

[CHENXCHEN]

Summary

Adds an opt-in Chrome Tab Group browser carrier for AutoCLI browser commands.

The existing automation-window behavior remains the default. Users can explicitly enable tab-group-background to run browser commands inside a Chrome Tab Group without creating a new visible Chrome window or stealing the current active tab.

This PR also adds per-adapter browser carrier configuration so custom local adapters can opt into the new mode without requiring global config.

Why

The current default browser automation flow can create visible automation windows. During repeated or consecutive commands, this may leave multiple separate Chrome windows and interrupt the user's normal browser workflow.

Using a Chrome Tab Group gives AutoCLI a better background carrier: tabs can be grouped, collapsed, reused, and cleaned up after an idle timeout. This keeps automation work contained behind the user's current browsing session instead of scattering unmanaged windows across the desktop.

The goal is to reduce user disruption while preserving the existing default behavior for compatibility.

Technical Details

• Adds browser carrier config:
  • automation-window remains the default
  • tab-group-background is the new strict background mode
• Supports config from:
  • ~/.autocli/config.json
  • environment variables
  • per-adapter YAML browser object
• Per-adapter config overrides environment variables and global config.
• Tab Group names use AutoCLI-${groupName}.
• If tab-group-background is selected without a valid groupName, it defaults to default, producing AutoCLI-default.
• Strict background mode does not fall back to a new window or activated tab.
• Reused same-title groups only clean up tabs created by AutoCLI, not user-owned tabs already in the group.
• tabs select is unsupported in strict background mode because it would require activating a tab.

Usage

Global config:

{
  "browser": {
    "carrier": "tab-group-background",
    "groupName": "work",
    "groupIdleTimeoutSeconds": 30
  }
}

Environment variables:

AUTOCLI_BROWSER_CARRIER=tab-group-background
AUTOCLI_BROWSER_GROUP_NAME=work
AUTOCLI_BROWSER_GROUP_IDLE_TIMEOUT=30

Per-adapter config:

browser:
  carrier: tab-group-background
  groupName: work
  groupIdleTimeoutSeconds: 30

Existing adapter syntax remains compatible:

browser: true

Test Plan

• cargo test -p autocli-browser -p autocli-discovery -p autocli-core
• cargo check -p autocli
• pnpm exec vitest run
• pnpm typecheck
• pnpm build
• git diff --check
• Manual Chrome smoke test with local release binary:
  • AUTOCLI_BROWSER_CARRIER=tab-group-background AUTOCLI_BROWSER_GROUP_NAME=work AUTOCLI_BROWSER_GROUP_IDLE_TIMEOUT=30 autocli read https://example.com --format text
  • Verified output from example.com
  • Verified current active tab was not switched
  • Verified no new Chrome window was opened
  • Verified AutoCLI-work group was created collapsed
  • Verified idle cleanup removed the AutoCLI-created tab/group after timeout

Known Quirks / Pitfalls

• Chrome shows its native debugger infobar ("AutoCLI" started debugging this browser) while commands are attached through the debugger API. This is Chrome behavior, not a new window or tab activation.
• In strict background mode, if the extension service worker is not connected, AutoCLI fails instead of waking Chrome by opening a window. Reloading the unpacked extension reconnects it.