User-side write path for agent memory (onboarding form / settings UI)

[michaelzwang13]

Problem

Phase D (#10, shipped in PR #25) added persistent per-agent memory, but the only write path is agent-side: the LLM reads a task like "remember I prefer concise reviews", decides to call the update-memory skill, and the skill POSTs to /gateway/memory with the agent's bearer token.

POST /gateway/memory is gated by get_current_agent — a user with their X-Api-Key literally cannot hit it. So users have no direct way to set preferences; they have to converse with the agent and hope it persists the right thing.

For a usable hire-to-first-good-review loop this is too slow. We should let users seed memory directly.

Proposal

Add a user-side endpoint and surface it in the UI.

Backend:

• New endpoint POST /agents/{id}/memory (and a matching GET/DELETE) gated by get_current_user (X-Api-Key), scoped to agents owned by the calling user.
• Writes to the same agent_memory table — the dispatcher's injection path already covers it on the next dispatch, no new plumbing needed.
• Decide: do agent-side writes via the skill still go through require_action("agent.memory.write")? (Yes — keep the policy check; the user-side path is a separate auth surface that doesn't need it.)

Frontend:

• Surface during onboarding (depends on #13) — "any review preferences?" → 2-3 free-text keys → POST.
• Optional later: a settings tab on the employee profile for CRUD on memory keys.

Why we didn't build it first

The agent-side path is the deeper one — it requires the LLM to recognize a preference statement and choose to persist it, which is the "employee" behavior the product is selling. The user-side path is plain CRUD; cheap to add once the UI exists.

Done when

• POST /agents/{id}/memory writes a key to agent_memory and dispatching a task to that agent injects it via role_context.
• A user can set at least one preference key from the UI during or after onboarding.

Depends on

• #13 for the UI placement (or ship the backend now and gate the UI on the do-over).