Add verify-website docs page

[maksika]

Context

The WayID app renders a canonical .well-known/wayid.toml header that references a docs page:

```toml

wayID domain verification file

See https://docs.way.je/verify-website for details

```

That page doesn't currently exist on docs.way.je. Builders who copy the TOML and open the link land on a 404.

See the code reference: https://github.com/LineageLabs/openclaw-prototype/blob/staging/src/lib/server/verification/shared.ts (function `generateWayidToml`). The corresponding app PR that corrects the hostname (previously pointed at `way.je/docs/verify-website`) is LineageLabs/openclaw-prototype#155.

What the page should cover

The audience is a builder who already has a WayID account and is proving they control a website or agent domain. The content should explain both the shipped website-social / custom-link flow and the newer claim-flow Domain channel (E8-S10) because both verifiers read the same `.well-known/wayid.toml` artefact but with different stanzas. Suggested outline:

1. What the file is and where to put it.

   • Serve at `https://{your-domain}/.well-known/wayid.toml`, HTTP 200, `Content-Type: application/toml` or `text/plain`.
   • No redirects — WayID fetches with `redirect: 'manual'` so a 302 to another host fails the check.
   • Standard CA HTTPS required; self-signed / expired certs are rejected by the outbound fetch.

2. Social / custom-link variant (what exists today).

   ```toml

   wayID domain verification file

   See https://docs.way.je/verify-website for details

   [wayid]
   version = 1
   user_id = "{user_uuid}"
   verification_token = "wayid-verify-{16 hex}"
   ```

   • Keys: `version` (integer 1), `user_id`, `verification_token`.
   • Token is HMAC-derived from (user_id, platform, url, discriminator) — re-derivable, never stored server-side. Builders get it from the Dashboard "Verify" modal.

3. Claim-flow Domain-channel variant (new in E8-S10).

   ```toml
   [wayid]
   version = "1"
   did = "wayid:agent:{24-char-base58}"
   pk = "ed25519/{base64}" # optional, only if a runtime key is attached
   nbf = 2026-04-24T12:00:00Z # not-before, TOML offset datetime
   exp = 2027-04-24T12:00:00Z # expiry; exp - nbf ≤ ~13 months
   ```

   • Keys: `version` (string "1" — note the quoting difference from the social variant), `did`, optional `pk`, `nbf`, `exp`.
   • The DID is pre-computed by WayID at pairing-token issuance time and shown to the operator in the claim wizard.
   • `nbf` / `exp` bound the binding's validity; the verifier refuses windows longer than ~13 months. Rationale: prevents stale-but-still-online TOMLs from anchoring a binding forever, and gives the future cadence re-check a concrete expiry per anchor.

4. Combining both stanzas. Single file can serve both verifiers at once — keys don't overlap. If combining, use the claim-flow string form for `version` (`"1"`); the social verifier accepts either.

5. Troubleshooting. Common failure modes with their diagnostic copy:

   • 404 → file not published or wrong path.
   • 302 redirect → WayID doesn't follow redirects. Serve the file directly on the claimed host.
   • TLS / network error → check the cert and that HTTPS is actually live.
   • `did` mismatch → the DID in the TOML doesn't match the one WayID issued for the current claim; re-copy from the wizard.
   • Time-window rejections → `nbf` in the future, `exp` past, window too long.

Happy to write drafts, but posting the outline here so someone with commit access to the Docs repo can shape it to the site's voice.