Add free-text api_instructions field to Sites

For custom sites we'll post to via their own API — there's no wired-in
publisher for these, so this is where the site owner documents how to
actually post there (auth, endpoints, payload shape). Shown in the UI
for non-WordPress sites, exposed via the JSON API, and pointed to from
AI_API.md's "any other network/CMS" fallback section so an agent checks
it before improvising.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

AI_API.md

@@ -82,12 +82,21 @@ Response shape:
     "cms_type": "wordpress",
     "wp_username": "admin",
     "wp_app_password": "abcd 1234 efgh 5678",
+    "api_instructions": null,
     "created_at": "2026-07-19T12:00:00.000000Z",
     "updated_at": "2026-07-19T12:00:00.000000Z"
   }
 }
 ```
 
+`api_instructions` is a free-text field (nullable) for `cms_type=custom`/`other`
+sites — there's no built-in publisher for these yet, so this is where the
+user documents how to actually post there: auth method, endpoints, payload
+shape, whatever's needed. **Read it before improvising** when you're about
+to publish to a site with no wired-in publisher (see "Any other
+network/CMS" below) — it's the site owner telling you directly how their
+API works, rather than you having to guess or ask.
+
 `cms_type` is one of `wordpress`, `custom`, `other`. `wp_username`/
 `wp_app_password` are only meaningful (non-null) when `cms_type` is
 `wordpress` — they're a WordPress **Application Password** pair (see
@@ -269,11 +278,12 @@ integration yet)
 
 There is no built-in publishing path. Do it however is appropriate for
 that platform (its own API, its own automation), using the credentials
-from `GET /api/sites` / `GET /api/accounts`, then report back via
-`PATCH /api/posts/{id}` exactly as described above. This is the general
-fallback contract: **whatever publishes a post, always ends with either
-the `posts:publish` command's automatic bookkeeping, or a manual `PATCH`
-setting `status` and, if applicable, `published_url`.**
+from `GET /api/sites` / `GET /api/accounts` — check the site's
+`api_instructions` first, that's exactly what it's there for — then report
+back via `PATCH /api/posts/{id}` exactly as described above. This is the
+general fallback contract: **whatever publishes a post, always ends with
+either the `posts:publish` command's automatic bookkeeping, or a manual
+`PATCH` setting `status` and, if applicable, `published_url`.**
 
 ## Quick reference