openlatch-provider 0.2.2

Self-service onboarding CLI + runtime daemon for OpenLatch Editors and Providers
# Auth

`openlatch-provider login` runs the same PKCE + browser-loopback flow
as `openlatch-client`. The token (an editor API key shaped
`olk_edt_live_...`) is stored in your OS keyring with an encrypted-file
fallback for headless Linux.

## Login flow

```bash
openlatch-provider login
```

1. Generates a PKCE `code_verifier` + SHA-256 `code_challenge`.
2. Binds a one-shot HTTP listener on `127.0.0.1:0` (OS-assigned port).
3. Opens `https://app.openlatch.ai/cli-auth?...` in your browser.
4. After you approve, the platform redirects to the loopback URL with
   a one-time code; the CLI exchanges the code for an editor token.
5. Stores the token in:
   - macOS Keychain (`apple-native`)
   - Windows Credential Manager (`windows-native`)
   - Linux Secret Service (`sync-secret-service`)
   - or, on headless Linux, an AES-256-GCM file at
     `~/.openlatch/provider/auth.toml` (HKDF-SHA256 over the persistent
     `machine_id`, mode 0600).

## Service prefixes

| Backend | Service | Username |
|---|---|---|
| Keyring | `openlatch-provider` | `editor-token` |
| File fallback | (n/a) | `~/.openlatch/provider/auth.toml` |

## Logout

```bash
openlatch-provider logout
```

Revokes the token server-side via `DELETE /api/v1/api-keys/self` and
clears the local entry.

## CI / non-interactive

Two env-var paths bypass the keyring:

- `OPENLATCH_TOKEN=olk_edt_live_...` — short-lived per-invocation.
- `--token-file /path/to/file` — file-based for orchestrators that
  rotate tokens.

Tokens NEVER come in via a CLI flag (`--token=...`) — that leaks the
secret to `ps` and shell history. The CLI explicitly refuses.

## Profiles

`~/.openlatch/provider/config.toml` supports multiple named profiles:

```toml
[profiles.default]
manifest_slug = "my-editor"

[profiles.staging]
manifest_slug = "my-editor-staging"
```

Activate with `--profile staging` or by setting
`OPENLATCH_PROVIDER_PROFILE=staging`.

## Refresh

Tokens issued by the platform have a long expiry (typically 1 year).
`openlatch-provider whoami` validates the token against the platform
on every call; an expired token surfaces `OL-4200`.

## Known issues

- **Linux + no Secret Service**: install `gnome-keyring` /
  `kwallet-pam` for the keyring path, or accept the encrypted-file
  fallback (it derives the key from `machine_id`, so the file is
  bound to the host).
- **Windows + Service accounts**: the Credential Manager backend
  only sees the running user's vault. For service accounts, set
  `OPENLATCH_TOKEN` in the service's environment and skip `login`.