Finalize UI truthfulness and bootstrap hardening

docs/modules/cli/architecture.md

@@ -118,7 +118,8 @@ See [migration-v3.md](./guides/migration-v3.md) for user-facing migration instru
 
 * `auth login`
 
-  * Modes: **device‑code** (default), **client‑credentials** (service principal).
+  * Modes: **interactive password** (current default for seeded `stellaops-cli` in fresh local/dev shells), **client-credentials** (service principal), and future **device-code/PKCE** once enabled by the Authority profile.
+  * Startup Authority/crypto diagnostics are opt-in via `--verbose` and stay suppressed for structured output flags such as `--json`, `--raw`, and `--format json`.
   * Produces **Authority** access token (OpTok) + stores **DPoP** keypair in OS keychain.
 * `auth status` — show current issuer, subject, audiences, expiry.
 * `auth logout` — wipe cached tokens/keys.
@@ -379,8 +380,17 @@ All verbs require scopes `policy.findings:read`, `signer.verify`, and (for Rekor
 
 ### 3.1 Token acquisition
 
-* **Device‑code**: the CLI opens an OIDC device code flow against **Authority**; the browser login is optional for service principals.
-* **Client‑credentials**: service principals use **private_key_jwt** or **mTLS** to get tokens.
+* **Human interactive login (current local/dev behavior)**: when `STELLAOPS_AUTHORITY_CLIENT_ID` is unset, the CLI defaults to the seeded `stellaops-cli` public client and prompts for username/password if they are not preconfigured. That login uses the current password-grant bootstrap path.
+* **Client-credentials**: service principals use a confidential client such as the seeded local/dev `stellaops-cli-automation`, or a deployment-specific confidential client with **private_key_jwt**, `client_secret`, or **mTLS**.
+* **Device-code/PKCE**: still the intended long-term human posture, but not yet the default fresh-shell path in the current local/dev Authority profile.
+
+### 3.1.1 Bootstrap client inventory (current local/dev standard profile)
+
+* Authority seeds first-party CLI clients from `etc/authority/plugins/standard.yaml`.
+* `stellaops-cli` is the default human client ID when no explicit Authority client ID is configured.
+* `stellaops-cli-automation` is the seeded confidential automation client for non-interactive local/dev flows.
+* Production deployments should override local secrets and may disable the password grant entirely once device-code or browser-mediated PKCE is enabled.
+* Startup Authority and crypto diagnostics are emitted only for verbose human-readable invocations; structured output commands stay clean even when optional crypto providers are unavailable.
 
 ### 3.2 DPoP key management
 
@@ -585,7 +595,7 @@ sequenceDiagram
   participant SG as Signer
   participant AT as Attestor
 
-  CLI->>Auth: device code flow (DPoP)
+  CLI->>Auth: password grant bootstrap on seeded stellaops-cli client
   Auth-->>CLI: OpTok (aud=scanner)
 
   CLI->>SW: POST /scans { imageRef, attest:true }
@@ -629,10 +639,13 @@ sequenceDiagram
 
 ## 19) Example CI snippets
 
-**GitHub Actions (post‑build)**
+**GitHub Actions (post-build)**
 
 ```yaml
-- name: Login (device code w/ OIDC broker)
+- name: Login (service principal)
+  env:
+    STELLAOPS_AUTHORITY_CLIENT_ID: stellaops-cli-automation
+    STELLAOPS_AUTHORITY_CLIENT_SECRET: ${{ secrets.STELLAOPS_AUTHORITY_CLIENT_SECRET }}
   run: stellaops auth login --json --authority ${{ secrets.AUTHORITY_URL }}
 
 - name: Scan