fix(sso): launch the SSO browser through the launcher abstraction

[sbldevnet]

Fixes #602

The bug

The device-code login flow executed the configured browser binary with the URL
as a bare argument:

/Applications/Safari.app/Contents/MacOS/Safari https://…/#/device?user_code=XXXX-XXXX

Safari does not parse a URL from argv. It resolves the argument as a file
path relative to its sandbox home, so users got a tab pointing at
~/Library/Containers/com.apple.Safari/Data/https:/… and the login never
completed. exec.Command succeeded, so Granted reported no error.

Granted already knew how to launch Safari correctly — open -a Safari <url> —
but only on the console path. The browser-key switch existed in two diverged
copies (pkg/assume/assume.go, pkg/granted/console.go) and the SSO path had
no dispatch at all.

This is not an unusual configuration. Selecting Safari in granted browser set-sso stores exactly this path, so following the documented setup is enough
to end up with a broken SSO login.

The fix

Factor the switch into launcher.ForBrowser and route all three call sites
through it. The Launcher interface moves from pkg/assume to pkg/launcher
so pkg/idclogin can use it without importing the assume command.

Browser identification goes through browser.GetBrowserKey, which now matches
only the executable's base name. It compares with unanchored substrings — which
is what lets one implementation handle a macOS bundle ID, a Linux .desktop
file and a Windows ProgId — but the directory components of a path are chosen by
the user. Without the base name restriction, /Users/marcus/bin/browser matches
"arc" and launches Arc. This also means browsers installed outside their default
location are now recognised (/opt/homebrew/bin/firefox).

ChromeProfile now omits --profile-directory when no profile is given. Both
the SSO flow and granted console launch without one, and an empty
--profile-directory= changes which profile the browser opens.

Compatibility

Paths that Granted does not recognise keep being executed directly, which is the
behaviour those configurations already have. Only browsers Granted recognises —
and currently mishandles — change.

Behaviour changes on the console path

Both console commands shared the switch, so unifying it fixes two gaps in the
granted console copy:

• ChromeProfile now receives the BrowserType it was missing, so Chrome
  profile lookup no longer silently no-ops.
• Arc, Waterfox, Firefox Developer Edition and Firefox Nightly use their own
  launchers instead of falling through to open. Previously, configuring Arc in
  Granted still opened whatever the OS default browser was.

These warrant a release note.

Testing

• Unit tests for ForBrowser argv per browser key, GetBrowserKey across all
  three input domains (display names, vendor identifiers, executable paths),
  ChromeProfile profile resolution against a fake Local State, and the
  idclogin wiring.
• Manually on macOS with the exact configuration from the bug report: Safari now
  emits open -a Safari <url> and the login completes. Chrome, an unrecognised
  binary, the launch-template path and the unconfigured fallback were each
  checked against the debug launch command.