fix: thread triples reference the thread row id, not its t- id (GIT-105)

[nTEG-dev]

What

Thread triples reach knowledge_triples on a v1.8.0 store (GIT-105). No schema change.

• source_id is now the thread's row id (gitmem_threads.id, a UUID the store already has), with source_type: "thread". It used to be the text thread_id (t-xxxxxxxx).
  • create_thread passes the row id createThreadInSupabase returns, so there's no extra request.
  • Resolution triples look it up by thread_id (one GET gitmem_threads?select=id&thread_id=eq.…).
  • A failed or empty lookup writes the triple with source_id: null instead of losing it. The subject/object labels still carry the relation.
• writeTriples never sends a non-UUID source_id from any caller: it logs and sends null.

Why

knowledge_triples.source_id is UUID in every schema, including v1.8.0:schema/setup.sql. Writing "t-b4d09cb0" into it failed the row with 22P02 invalid input syntax for type uuid, so every create_thread and resolve_thread triple 400'd, and the failure was swallowed. The table has no JSONB column to stash the text id in. The row id is the value that actually fits the column's meaning, and nothing reads source_id back as a thread id: graph_traverse only displays it, and the scar lookup filters on learning UUIDs.

How to test

Venue (v1.8.0 setup.sql, vujndhcumgroztfkkdus; production not touched). GIT-105 is removed from EXPECTED_FAILURES, which leaves only GIT-73 on this branch (GIT-73's own PR, #42, removes that one). flow now reads knowledge_triples?source_type=eq.thread back and requires every source_id to be a real gitmem_threads.id.

	origin/main 1.10.0	This branch
POST knowledge_triples	400 (22P02)	201
Thread triples stored	0	1, linked to its thread row
Exit	1	0, no expected failures seen

The resolution path isn't driven on the venue in this branch (the resolve step arrives with GIT-101's driver change, #40). It's covered by unit tests: lookup by thread_id, not found → null, lookup failure → null.

Unit tests: 1279/1279 pass (+5). Creation uses the passed row id with no lookup; resolution looks it up; not-found and lookup failure → null with the triple still written; a non-UUID source_id from any caller → null; extraction without a row id → null, never the thread_id.

Existing tests that encoded the old behaviour (changed, not deleted)

tests/unit/services/thread-triples.test.ts: sets correct source_type and half_life on all triples and has correct subject/object labels asserted source_id === "t-abc12345", the exact value the UUID column rejects. They now pass a thread_row_id in the fixture and expect it as source_id. All other assertions are unchanged.

Checklist

• npm run test:unit passes (1279)
• New tests added
• No schema change; verified on a v1.8.0 store
• Docs: n/a

Breaking changes

None. Thread triples previously never landed, so there are no existing rows to be inconsistent with.

🤖 Generated with Claude Code