feat(duo): warn when running duo cli under snap confinement

What does this MR do and why?

Detect snap confinement at the start of glab duo cli and surface an explanatory warning before the (doomed) run proceeds.

Background

The Duo CLI authenticates by spawning glab auth credential-helper and parsing its JSON output (source). Under snap strict confinement, the downloaded Duo binary (living under ~/snap/glab/<rev>/.gitlab/...) cannot exec back into /snap/bin/glab — AppArmor blocks it. Users see a confusing Credentials source: no credentials found and No token provided error even after a successful glab auth login.

The diagnosis trace in the Duo logs:

[CredentialProvider] Attempting to fetch credentials from glab credential-helper
[CredentialProvider] glab is not installed or not found in PATH
[CredentialProvider] No credential available from glab

Change

In internal/commands/duo/cli/cli.go, before invoking the runner for the normal glab duo cli path (skipped for --install / --update), check os.Getenv("SNAP"). If set, print a clear warning explaining the limitation and pointing at non-snap install paths (Homebrew, mise, native binary).

This only changes the UX — the run still proceeds in case the user has a working env-var-based auth fallback. It does not error out.

Why this is a UX fix only, not a real fix

The credential-helper protocol requires duo to find and exec glab from its own (sandboxed) process. There is no glab-side code change that fixes that under strict snap confinement. The architecturally correct fix is to have glab pass the token to duo via an env var on syscall.Exec, bypassing the callback entirely — but that requires upstream support in gitlab-lsp's credential provider. Tracked separately in a confidential issue.

Test plan

• go test ./internal/commands/duo/cli/... passes
• go build ./... passes
• go vet ./internal/commands/duo/cli/... clean
• Manual: on a Linux box with snap-installed glab, run glab duo cli and verify the warning appears with the expected install-method suggestions