refactor(setup): derive setup-complete status from admin user count

Setup completion was previously tracked by a manually-flipped setup_complete row in system_settings, written via a JWT-protected PUT /api/setup/complete endpoint. This meant any admin user created outside the setup wizard (future CLI, seed scripts, direct DB inserts) would not flip the switch, leaving the app stuck redirecting to /setup.

The trigger is now derived from real data: setup is complete iff at least one admin user exists. This is self-correcting regardless of how users are created, and re-engages setup automatically if all admins are ever removed.

Changes:
- Add internal/setupstatus package with IsSetupComplete() (queries CountAdmins, 10s in-memory cache, fails open on DB error) and Invalidate() to clear the cache. Uses an AdminCounter interface to avoid importing the database package.
- Add CountAdmins sqlc query (SELECT COUNT(*) FROM users WHERE role = 'admin') and regenerate.
- Rewire router/setup.go isSetupComplete() to delegate to setupstatus; drop the old setup_complete setting read, cache vars, and the PUT /api/setup/complete route.
- Call setupstatus.Invalidate() in the auth handler after CreateUser, UpdateUserRole, and DeleteUser so the cache reflects admin-count changes immediately.
- Align first-user promotion in Register to key off !adminExists instead of len(users) == 0, so the two checks cannot diverge.
- Remove the now-dead SetSetupComplete/GetSetupStatus handlers.
- Drop the setup_complete seed row from schema.sql.
- Remove the apiPut('/setup/complete') call from the setup wizard finishSetup(); the admin account created in submitAdmin already marks setup complete server-side.

internal/setupstatus/status.go

@@ -0,0 +1,62 @@
+// Package setupstatus reports whether the application's initial setup has been
+// completed. Setup is considered complete as soon as at least one admin user
+// exists, regardless of how that user was created (setup wizard, API, or a
+// future CLI). This keeps the setup gate a derived property of real data
+// rather than a manually-flipped flag that can drift out of sync.
+package setupstatus
+
+import (
+	"context"
+	"sync"
+	"time"
+)
+
+// AdminCounter is satisfied by *database.Queries. It is defined as an interface
+// here so this package does not import the database package, keeping the
+// dependency graph flat and avoiding import cycles.
+type AdminCounter interface {
+	CountAdmins(ctx context.Context) (int64, error)
+}
+
+var (
+	cacheMu       sync.RWMutex
+	cacheComplete bool = true
+	cacheExpiry   time.Time
+	cacheTTL           = 10 * time.Second
+)
+
+// IsSetupComplete reports whether setup is complete. Setup is complete when at
+// least one admin user exists. A short in-memory cache avoids hammering the
+// database on every request. On a database error the function fails open
+// (returns true) so a transient outage does not lock users out of the app.
+func IsSetupComplete(ctx context.Context, q AdminCounter) bool {
+	cacheMu.RLock()
+	if time.Now().Before(cacheExpiry) {
+		complete := cacheComplete
+		cacheMu.RUnlock()
+		return complete
+	}
+	cacheMu.RUnlock()
+
+	count, err := q.CountAdmins(ctx)
+	complete := true
+	if err == nil {
+		complete = count > 0
+	}
+
+	cacheMu.Lock()
+	cacheComplete = complete
+	cacheExpiry = time.Now().Add(cacheTTL)
+	cacheMu.Unlock()
+	return complete
+}
+
+// Invalidate clears the cached setup status so the next call to IsSetupComplete
+// re-reads from the database. Call this after any write that could change the
+// admin user count (user creation, role promotion/demotion, user deletion).
+func Invalidate() {
+	cacheMu.Lock()
+	cacheComplete = true
+	cacheExpiry = time.Time{}
+	cacheMu.Unlock()
+}