feat: add a keyring provider for the OS credential store

[husniadil]

Stacked on #149. This branch builds on fix/json-value-stringification,
so until that merges the diff below also shows #149's commits. The keyring
work is the last four commits. Happy to rebase once #149 lands, or to close
this and reopen if you would rather take them separately.

What this adds

A keyring provider that reads a secret from the operating system's credential
store: Keychain on macOS, Credential Manager on Windows, Secret Service on Linux.

providers:
  - kind: keyring
    id: db
    service: myapp
    user: postgres

sstart already depends on zalando/go-keyring and already uses it for the
secrets cache and for OIDC token storage. Nothing exposed it as a source of
secrets, so the one credential store a developer's machine already has — backed
up by the OS backup tool, unlocked by the OS login — was the one place sstart
could not read from.

No build tags and no platform gating: go-keyring ships a native backend for
each platform, so there is no platform to reject.

Why it is named keyring

The codebase already says "keyring" everywhere, including the exported
StorageBackendKeyring = "keyring" in internal/oidc/storage.go. "Keychain" is
Apple's product name, and naming it that would hide the provider from Windows
and Linux users who are equally supported.

Reading into a payload

A credential item often holds a JSON blob rather than one secret. Read whole,
every secret inside it is exported to the child process. The optional pointer
field selects one node first:

  - kind: keyring
    id: claude
    service: Claude Code-credentials
    user: husni
    pointer: /claudeAiOauth/accessToken
    key: CLAUDE_TOKEN

pointer is an RFC 6901 JSON pointer rather than a dotted path because real key
names contain dots, pipes and colons — a live example is
plugin:engineering:github|1eea5f27. RFC 6901 already defines the escaping, and
gives array indices (/scopes/0) for free.

It is called pointer and not path because path already means "where the
secret lives" in dotenv, infisical and vault. A test asserts that a stray
path: is not silently read as a pointer.

Note that no application's schema is encoded in sstart. The pointer lives in the
user's config, so a different vendor's credential shape needs a different
pointer, not a new sstart release.

Behaviour

Without pointer, a JSON object is expanded into one variable per key, honouring
keys exactly as the cloud providers do; anything else becomes a single variable
named <PROVIDER_ID>_SECRET, or key if given. With pointer, the selected node
goes through the same rule. Values follow the conversion in #149.

service and user are both required: go-keyring exposes only
Get/Set/Delete/DeleteAll, so without enumeration an item is unreachable
without its exact identity.

Two deliberate choices worth flagging for review:

An unavailable keyring is an error, not a silent skip. The cache disables
itself quietly because a miss only costs a re-fetch. A provider that yields
nothing instead hands the child process an environment with no secrets in it.

No sync.Once availability probe, unlike internal/cache/cache.go. The
provider makes exactly one keyring call regardless, so a probe would only add a
second credential-store access — and on macOS a second access prompt — to learn
what the real call is about to report. Mapping the error from Get gives the
same two outcomes with no package-level mutable state.

Read-only

There is no write path, and no sstart keyring set. Adding a write command
changes what sstart is, and that is a call for you to make rather than something
to slip in with a provider. CONFIGURATION.md documents how to populate the
store with each platform's own tool.

Verification

• 27 unit tests for the provider, against go-keyring's MockInit() and
  MockInitWithError() — no OS keyring and no container needed, including the
  keyring-unavailable path.
• Pointer resolver tested separately: escaped ~0/~1, array indices, keys
  containing | and :, and the error cases.
• One test asserts a pointer does not leak its siblings, which is the entire
  reason the field exists.
• Real macOS Keychain: whole-item read, pointer narrowing, and a missing-node
  error all verified against an item created with security add-generic-password
  and deleted afterwards.
• Real Linux, inside golang:1.25: both packages pass, the binary builds with
  CGO, and a headless host with no Secret Service produces
  exec: "dbus-launch": executable file not found in $PATH. On Linux this usually means no Secret Service is running, which is common on headless hosts.
  errors.Is(err, ErrNotFound) is false there, so the unavailable branch is
  taken rather than the not-found one.
• Full -short ./tests/end2end/... passes locally with Docker (365s).
• go build ./... and go vet clean.

Not verified: Windows Credential Manager. I have no Windows machine to test
on, so the docs make no claim about it beyond the backend go-keyring uses.

internal/cache, internal/provider/gcsm and internal/provider/vault unit
tests fail on main today. I confirmed they fail identically at this branch's
starting commit, before any of this work. #148 fixes them.

Registration

internal/cli/root.go gets the blank import. Without it the package compiles and
every test passes while the binary reports unknown provider kind: keyring —
the same failure #146 fixes for azure_keyvault. Verified by building the binary
and running it against a keyring config.