docs(client): document ClearanceOptions.scope as reserved (#41)

Author: cport1

CHANGELOG.md

@@ -13,6 +13,8 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Changed
 
+- **`ClearanceOptions.scope` is documented as reserved.** It was described as a route-group scope that limits where a token is valid. No validator enforces that: a clearance token is bound to the organization, and each protected path's verification level is the way to require stronger proof. Passing `scope` (or `data-scope` on the script tag) still works and still has no effect.
+
 - **One adapter core.** Express, Fastify, Next.js (middleware and Pages wrapper) and the fetch guard each carried their own copy of skip-path matching, the 429 and 403 payloads, and honeytoken arming — five copies of one set of decisions, and five places the next correction can fail to land. They now share `adapter-core.ts`; the framework-specific response mechanics are untouched, and every honeytoken-injection test passes unchanged. Fastify keeps its awaited arming, which has no window where early requests are served without the link.
 
 ## [0.13.0] - 2026-08-22

packages/client/src/clearance.ts

@@ -152,7 +152,13 @@ export interface ClearanceOptions {
   siteKey: string;
   /** WebDecoy ingest origin. Defaults to DEFAULT_INGEST_URL. */
   ingestUrl?: string;
-  /** Route-group scope; '' = tenant-wide (default), valid on every route. */
+  /**
+   * Reserved. Sent with the mint request, but no validator restricts a token by
+   * it. A clearance token is bound to the organization: any of its sites accepts
+   * it, subject to expiry, the fingerprint deny list and the verification level
+   * required by the path it is used on. Use a path's verification level to ask
+   * for stronger proof on sensitive routes.
+   */
   scope?: string;
   /**
    * Collect interaction aggregates and upgrade the token to a graded