feat(snap): expose password-manager-service plug and guide users to connect it

What does this MR do and why?

The glab snap ships under strict confinement, and the manifest at snap/snapcraft.yaml doesn't declare any interface that lets the process talk to the D-Bus Secret Service. As a result, glab auth login on the snap always falls through to the plaintext fallback and prints:

WARNING: The operating system keyring is unavailable. Storing credentials as plaintext in the configuration file.

The warning offers no path forward, so users file bugs (#8496 (closed)).

This MR:

1. Adds the password-manager-service plug to the snap manifest. snapd does not auto-connect this interface, so users still need to opt in with sudo snap connect glab:password-manager-service — but the plug has to exist for that command to work at all. The reporter of #8496 (closed) hit exactly this: sudo snap connect glab:password-manager-service failed with snap "glab" has no plug named "password-manager-service".
2. Extends the existing plaintext-fallback warning in internal/commands/auth/login/login.go and the plaintext-migration nudge in internal/commands/auth/status/status.go to name the exact snap-connect command when running under snap confinement.
3. Adds a small SnapConfined() helper in internal/commands/auth/authutils/snap.go. Detection uses the SNAP environment variable that snapd sets on every confined process, matching the pattern already used by glab duo cli in internal/commands/duo/cli/cli.go.
4. Adds a Credential storage section to docs/source/authentication.md covering keyring behavior across platforms, the plaintext fallback, and the snap-specific requirement. Updates the Snapcraft step in docs/installation_options.md with the new snap connect command, parallel to the existing ssh-keys step.

Users not running under snap see zero change.

Why not request auto-connect?

Auto-connect for password-manager-service is rarely granted — reviewers have declined similar requests even for well-known password-adjacent CLIs (Bitwarden, Actioneer). We can still open a Store request separately, but the manual-connect path is what users will realistically experience, so the tool and docs should teach them the exact command.

User experience

Fresh snap install:

$ sudo snap install glab
$ glab auth login
WARNING: The operating system keyring is unavailable. Storing credentials as plaintext in the configuration file.
glab is running under snap confinement. To enable OS keyring storage, run:
  sudo snap connect glab:password-manager-service
Then re-run glab auth login to migrate this token into the keyring.

Existing plaintext token, running glab auth status:

gitlab.com
  ✓ Token found in configuration file (plaintext): ****
  ! To store this token more securely, run glab auth login --hostname gitlab.com to move it into the operating system keyring.
    Under snap confinement, first run sudo snap connect glab:password-manager-service to grant keyring access.

Test plan

• make check passes locally (4345 tests, 0 lint issues).
• New unit tests: Test_keyringUnavailableUnderSnapShowsConnectHint (login), Test_statusRun_keyringMigrationHint_snapConfined (status), TestSnapConfined (helper).
• Existing plaintext-fallback tests explicitly clear SNAP and assert the snap hint is absent — protects against accidental output drift.
• Docs pass markdownlint, vale, and lychee (verified by lefthook run pre-push).
• Verified pre-merge on Ubuntu 24.04 (GCE VM) with this MR's own snapcraft_build_edge artifact: the plug is present, sudo snap connect glab:password-manager-service succeeds, and glab auth login then stores the token in the OS keyring, migrating it out of the plaintext config file. Full results in this comment.

Closes #8496 (closed).