GET and PUT /api/v1/user/notify read and set your phone notify URL, as MCP `notify` and Settings already do #7884

Intent: an agent or script with a person's token reaches the phone notify URL over REST, not only through MCP notify (src/http/mcp/tools/notify.ts) and Settings. Today GET /api/v1/user/notify is a 404 on production.

Done when:

• [ ] GET /api/v1/user/notify answers { set, host } (the host only, never the full URL), as MCP notify does with no url.
• [ ] PUT /api/v1/user/notify with { url } saves it, and an empty url turns it off; it answers { set, host } and appends account.notify_set to the bus, as the MCP tool does.
• [ ] An agent's token gets 403 forbidden; a write with a token that is not admin scope gets 403; a URL setNotifyUrl refuses gets 422 with the NOTIFY_ERRORS words; a cross-site browser write is refused like every other mutation.
• [ ] Both routes are described in src/contract/openapi/routes/ beside the other /api/v1/user routes, so GET /api/v1/openapi.json lists them.
• [ ] A test in test/ drives read, set, clear and each refusal through the HTTP API, and fails without the route.

Files: src/http/api/user.ts, src/contract/openapi/routes/ (two new files), a new test/api-user-notify.test.ts. Reuse src/crew/notify.ts; add no logic to the route that the MCP tool does not share.

Risks: leaking the full URL (it can hold a secret token) — answer the host only, and never log it. Keep away from src/http/server.ts and docs/MCP.md, which are hot.

Suggested builder: scout (API parity work).