`capture_thought` should return the new thought's UUID (already available from `upsert_thought`)

[TheAlphaEngineer]

Observed on main @ 67791060 (server/index.ts), during end-to-end testing of a live deployment.

What happens

capture_thought calls the upsert_thought RPC, which returns { id, fingerprint }. The handler already binds the id and uses it to write the embedding:

const { data: upsertResult } = await supabase.rpc("upsert_thought", { p_content, p_payload });
const thoughtId = upsertResult?.id;
await supabase.from("thoughts").update({ embedding }).eq("id", thoughtId);

But the tool response is only a human-readable confirmation and never surfaces the id:

let confirmation = `Captured as ${meta.type || "thought"}`;
// ...topics / people / actions appended...
return { content: [{ type: "text", text: confirmation }] };

Why it matters

update_thought and delete_thought both require the thought's UUID. A client that just captured a thought has no way to reference it without a follow-up search_thoughts / search round-trip — which is wasteful and racy (semantic search may not immediately surface the just-written row, and several similar captures are ambiguous). The id is already in hand server-side.

Suggested fix

Return the id — minimal change, no extra DB work:

return { content: [{ type: "text", text: `${confirmation} (id: ${thoughtId})` }] };

and/or add a structured { id } field. Not blocking (workable via search), purely an ergonomics gap that would make the capture → update/delete flow first-class.