privacy: state what the API path actually stores (and add it where members read)

The policy described chat history and enclave models carefully but never addressed
the API path, and §2 read as though all content is retained — which is wrong for
members using their own keys.

Verified before writing, rather than restating policy language: a request with a
distinctive marker was sent through the gateway and searched for afterwards. It
appears nowhere in the gateway's logs, `litellm_settings` enables no content
logging, and the request records carry usage fields only (model, tokens, cost, key).

- privacy-policy.md §2: content retention now depends on the surface, with a pointer.
- privacy-policy.md §4: new subsection on API requests, including the two limits that
  stop it being read as more than it says — we can still link a request to a key and
  therefore a member, and "not stored by us" says nothing about the provider.
- api-access.md: a "what we store" section, since that is the page an API user reads
  before worrying about it.
- models.md: the privacy-limitations section now distinguishes chat from API.

models.md

@@ -204,5 +204,8 @@ for their value (renewable energy, public models) but do not run in enclaves —
 prompts and responses pass through them in the ordinary way. Your **chat
 history** is also stored on our server so you can revisit it, and that stored
 history is not encrypted in a way that prevents us from technically reading it —
-we commit not to. The full distinction — what's architecturally private versus
-what's a policy commitment — is in the [Privacy Policy](privacy-policy.md).
+we commit not to. Requests made through the **API** with your own key are a
+different matter: those are **not stored on our side at all**, beyond the usage
+record needed for metering ([API access](api-access.md)). The full distinction —
+what's architecturally private versus what's a policy commitment — is in the
+[Privacy Policy](privacy-policy.md).