fix(profiles): correct the settings shape, job entity_type and status type

Four bugs that made the profile SDK unusable against the live API, each
found by running the demo notebook end to end rather than by reading.

1. `update_profile_settings()` sent a flat body:

       {"enabled": ..., "schema": ..., "custom_instructions": ...}

   The API takes only `enabled` and `entities` at the top level and
   answers 400 "Unsupported settings: custom_instructions, schema." to
   anything else, so every call passing a schema failed.
   `get_profile_settings()` already returned the nested shape, so the read
   and the write disagreed and the method could not round-trip its own
   settings. Both SDKs now nest `schema` and `custom_instructions` under
   `entities.<entity_type>` while keeping the flat call signature;
   `entity_type` is a new optional argument defaulting to "user".

2. `sample_profiles()` and `regenerate_profiles()` never sent
   `entity_type`. Every profile job must name an entity kind, so both
   failed with "entity_type must be one of: user, agent."

3. The TypeScript read path rewrote the customer's schema property names.
   Once the schema moved under `entities`, `snakeToCamelKeys` camel-cased
   the keys inside it, because only a top-level schema was restored
   verbatim. A field named `favorite_topics` came back as `favoriteTopics`.

4. `ProfileStatus` declared `notEnabled` and `insufficientData`, but a
   status is a value, not a key, so it is never camel-cased. tsc rejected
   `status === "insufficient_data"`, which is true at runtime, and accepted
   `status === "insufficientData"`, which can never fire. Branching on
   status is the documented way to use a profile, so the type steered
   every TypeScript caller into a dead branch.

Response-shape corrections found alongside them: sample returns
`entity_ids` on create and a richer `results` array on the job, so the TS
`results` field on the create response is marked deprecated and never set;
regenerate answers 409, not the 501 the docstrings claimed.

Verified against a live environment, from both SDKs: a settings write
followed by a read returns the schema property for property, a partial
update no longer blanks it, sample returns 202 with the entities it
picked, regenerate reaches the server and answers its real
not_yet_available, and a user with no profile returns "insufficient_data".

Adds a user-profiles demo notebook covering the whole loop: schema,
ingestion, generation, a before/after diff of a profile rewriting itself,
schema sampling, and a failure-scenario section for each way the API says
no. It polls the add event to a terminal status instead of sleeping, waits
for the extracted memory count to settle rather than trusting the first
page, and reports plainly when generation cannot finish instead of
presenting an empty profile as a result. Executed end to end: 0 failing
cells.

- python: 20 passed (tests/test_client_profiles.py)
- typescript: 203 passed (src/client/tests/)

docs/platform/features/user-profiles.mdx

@@ -276,11 +276,33 @@ On a project where profiles are turned off, a read returns `status: not_enabled`
 
 ## Settings reference
 
-| Field | Type | Description |
+| Argument | Type | Description |
 |---|---|---|
 | `enabled` | boolean | Whether profile generation runs for the project |
 | `schema` | object | JSON Schema describing the profile. Every property needs a `description` |
 | `custom_instructions` | string | Extra guidance applied during extraction |
+| `entity_type` | string | Which entity kind `schema` and `custom_instructions` apply to. Defaults to `user` |
+
+`enabled` is project-wide. `schema` and `custom_instructions` belong to one
+entity type, so the stored settings nest them under `entities`:
+
+```json
+{
+  "enabled": true,
+  "entities": {
+    "user": {
+      "schema": { "type": "object", "properties": { "...": {} } },
+      "custom_instructions": "Prefer durable traits over one-off remarks."
+    },
+    "agent": { "schema": null, "custom_instructions": null }
+  },
+  "capabilities": { "full_rebuild": false }
+}
+```
+
+That is what a read returns and what a write accepts. The SDKs take the fields
+flat and nest them for you, so a schema you write with
+`update_profile_settings` comes back unchanged from `get_profile_settings`.
 
 <Note>
   Profile settings are per project. An API key is scoped to one project, so profiles never cross a project boundary.