Fix change-tier API example and move install steps to the admin UI

agent.html

@@ -64,8 +64,8 @@ curl -X POST https://your-keysat-host/v1/admin/api-keys \
   -d '{"label":"Support bot","role":"support"}'
 # Response includes `token: ks_...`. Save it. It's only shown once.
 
-# 3. Use the scoped key
-curl https://your-keysat-host/v1/admin/licenses?status=active \
+# 3. Use the scoped key (admin/licenses requires a product_id)
+curl "https://your-keysat-host/v1/admin/licenses?product_id=<uuid>" \
   -H "Authorization: Bearer ks_..."</pre>
 
     <h2 id="auth">Authentication</h2>
@@ -245,11 +245,12 @@ curl -X POST $KS/v1/admin/subscriptions/$SUB_ID/cancel \
     <pre class="code">curl -X POST $KS/v1/admin/licenses/$LICENSE_ID/change-tier \
   -H "Authorization: Bearer ks_..." \
   -d '{
-    "target_policy_slug": "pro",
+    "to_policy_slug": "pro",
+    "skip_payment": true,
     "reason": "support resolution"
   }'</pre>
-    <p>Always applies as comp (no invoice) from the admin path. Buyer-initiated paid upgrades go through <code>/v1/upgrade</code> (different endpoint, signed-license auth).</p>
-    <p><em>Scope required: <code>licenses:write</code>.</em></p>
+    <p>With <code>skip_payment: true</code> this applies as a comp (no invoice). Omit it (defaults to false) and the admin path behaves like the buyer path: it creates an invoice for the prorated charge and returns the checkout URL. Buyer-initiated paid upgrades go through <code>/v1/upgrade</code> (different endpoint, signed-license auth).</p>
+    <p><em>Master admin key required.</em></p>
 
     <h3 id="connect-btcpay">Connect BTCPay programmatically (sandbox)</h3>
     <p>On a <strong>sandbox</strong> daemon (<code>KEYSAT_SANDBOX_MODE=1</code>), a scoped key carrying <code>payment_providers:write</code> can connect a BTCPay store over the API with no browser step, as long as the store settles on a <strong>non-mainnet</strong> network (regtest / testnet / signet). On a production daemon, or for a mainnet store, connect stays master-only. This is the path a delegated setup agent uses to stand up a disposable test instance end to end. You need a BTCPay API key for the target store (the operator's BTCPay access, delegated to you) carrying the same store and invoice permissions the browser flow grants (see <a href="install.html#connect-btcpay">Install &amp; setup</a>): the store-settings permissions complete the connect, and the invoice permissions let settled purchases issue licenses.</p>
@@ -375,7 +376,7 @@ def verify(body_bytes: bytes, signature_header: str, secret: str) -> bool:
     <p>List endpoints return up to ~100 rows by default. Use <code>?limit=N</code> and <code>?offset=N</code> for larger result sets. The OpenAPI spec documents the limits per endpoint.</p>
 
     <h3>Rate limits</h3>
-    <p>The admin endpoints have no per-IP rate limit today. Operators are trusted. The public endpoints (<code>/v1/validate</code>, <code>/v1/recover</code>) are rate-limited per client IP (10/min for <code>/recover</code>; <code>/validate</code> is unlimited but a reasonable agent calls it once per app boot + once per hour).</p>
+    <p>The admin endpoints have no per-IP rate limit today. Operators are trusted. The public endpoints (<code>/v1/validate</code>, <code>/v1/recover</code>) are rate-limited per client IP (10/min for <code>/recover</code>; <code>/validate</code> allows a 60/min burst per client IP, which a reasonable agent stays well under by calling it once per app boot + once per hour).</p>
 
     <h3>Master key handling</h3>
     <p>If your automation needs <code>full-admin</code> because it touches operator-only operations (creating other API keys, changing payment providers), use the master key from a secret manager. If it can stay within license / product / policy operations, <strong>always use a scoped key</strong>. Operators can revoke a compromised scoped key without rotating the master credential.</p>