docs: fix command mismatches in getting-started guides

Replace non-existent CLI commands with actual ones:
- `auths attestation issue` → `auths device link`
- `auths verify-commit` → `auths verify`
- `auths sign --file` → `auths sign` (positional arg)
- `auths id init` → `auths id create`
- `auths device revoke <did>` → `auths device revoke --device-did --key`
- `auths verify --attestation-chain` → `auths verify` (positional arg)

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: bordumb

docs/getting-started/delegation.md

@@ -47,11 +47,10 @@ The human's attestation has no `delegated_by` — this is the root of the chain.
 The human creates a scoped, time-limited attestation granting specific capabilities to an agent:
 
 ```bash
-auths attestation issue \
-  --subject did:key:z6MkAgentDevice... \
-  --signer-type Agent \
+auths device link \
+  --device-did did:key:z6MkAgentDevice... \
+  --key my-key \
   --capabilities "sign:commit,deploy:staging" \
-  --delegated-by did:keri:EHuman123... \
   --expires-in 24h
 ```
 
@@ -103,7 +102,7 @@ The sub-agent's capabilities are a strict subset of the parent agent's. The expi
 When a relying party receives a signed artifact, it verifies the full attestation chain using `verify_chain()`:
 
 ```bash
-auths verify --attestation-chain chain.json
+auths verify chain.json
 ```
 
 The verifier checks, from leaf to root:

docs/getting-started/identity-lifecycle.md

@@ -6,7 +6,7 @@ An Auths identity moves through distinct phases: creation, device linking, key r
 
 ```mermaid
 stateDiagram-v2
-    [*] --> Inception: auths id init
+    [*] --> Inception: auths id create
     Inception --> Active: Identity created<br/>KEL seq 0
     Active --> Active: Link device<br/>IXN event anchors attestation
     Active --> Rotated: Rotate keys<br/>ROT event, KEL seq +1
@@ -22,7 +22,7 @@ stateDiagram-v2
 Identity creation generates two Ed25519 keypairs and writes a single inception event to the Key Event Log.
 
 ```
-auths id init --alias my-key
+auths id create --local-key-alias my-key
 ```
 
 What happens internally:
@@ -121,7 +121,7 @@ After rotation:
 When a device is compromised or decommissioned, its attestation is revoked. Revocation is a signed event: the identity key signs a new attestation with the `revoked_at` field set.
 
 ```
-auths device revoke <device-did>
+auths device revoke --device-did <DEVICE_DID> --key <KEY_ALIAS>
 ```
 
 The revoked attestation replaces the original at the same Git ref path. The revocation is anchored in the KEL via an interaction event. After revocation, signatures from that device will fail verification (the verifier checks the `revoked_at` field).

docs/getting-started/sharing-your-identity.md

@@ -99,28 +99,26 @@ This gives the runner its own `did:keri` identity and device key, independent of
 A human operator issues an attestation granting the CI agent specific capabilities:
 
 ```bash
-auths attestation issue \
-  --subject did:key:z6MkCIRunner... \
-  --signer-type Workload \
+auths device link \
+  --device-did did:key:z6MkCIRunner... \
+  --key my-key \
   --capabilities "sign:commit,sign:release" \
-  --delegated-by did:keri:EHumanAdmin... \
   --expires-in 7d
 ```
 
 The attestation:
 
-- Uses `signer_type: Workload` to identify this as an automated process
 - Grants only `sign:commit` and `sign:release` — not `deploy:production` or `manage_members`
 - Expires in 7 days, requiring periodic re-authorization
-- Includes `delegated_by` linking back to the authorizing human
+- Links back to the authorizing human's identity through the attestation chain
 
 ### Agent signs artifacts
 
 The CI agent signs commits and releases using its own key:
 
 ```bash
 git commit -S -m "Release v2.1.0"
-auths sign --file release-v2.1.0.tar.gz
+auths sign release-v2.1.0.tar.gz
 ```
 
 Every signature is traceable through the attestation chain: `CI runner → human admin → organization`.
@@ -130,7 +128,7 @@ Every signature is traceable through the attestation chain: `CI runner → human
 Any verifier can validate the agent's work by checking the full chain:
 
 ```bash
-auths verify-commit HEAD
+auths verify HEAD
 ```
 
 The verifier confirms: the commit was signed by a device with a valid attestation, the attestation was issued by an authorized human, and the capabilities include `sign:commit`.