fix(extension): remove redundant setOptions call before opening side panel

[lcomplete]

Summary

• Removes the sidePanelApi.setOptions() call that was made before opening the side panel in openSidePanelForContextMenuClick
• The setOptions call (configuring tabId, path, and enabled) was redundant since sidePanelApi.open() handles opening directly

Test plan

• Verify side panel opens correctly via context menu click
• Confirm no regressions in side panel behavior

🤖 Generated with Claude Code

[augmentcode]

🤖 Augment PR Summary

Summary: Removes the pre-open chrome.sidePanel.setOptions() configuration in openSidePanelForContextMenuClick, relying on chrome.sidePanel.open()/manifest defaults instead.
Why: Simplifies the context-menu side panel open flow by dropping an apparently redundant options call.

_{🤖 Was this summary useful? React with 👍 or 👎}

[augmentcode]

Review completed. 1 suggestion posted.

Comment augment review to trigger a new review at any time.

[augmentcode]

setOptions({ tabId, path, enabled }) was the only place in this file that explicitly configured/enabled the side panel; after removing it, can you confirm the extension’s manifest/WXT build always provides the correct side_panel.default_path and that the panel is enabled by default for the target tab?
Otherwise sidePanelApi.open() may fail or open an unexpected/blank panel on Chrome versions that require setOptions to establish an active panel for the tab/window first.

Severity: medium

_{🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.}