feat(admin): a page for who is on the instance, and how somebody else gets on it

The README has promised "internal users are created by an admin" since the
beginning and there was no such thing. There are exactly two ways an
account has ever come into existence: the first admin at setup, and
somebody accepting an invite to a project. So the only way to add a person
was to share a project with them first.

The store has been ready the whole time. CreateInvite already documents
that "projectID may be empty, which invites somebody to the instance
rather than to a particular project", and AcceptInvite already has the
branch that grants no membership when there is none. requireAdmin has
existed in the middleware and was used nowhere. This wires those three
together and puts a page on them.

An invite rather than an account with a password the administrator picks.
A password typed here would be known to two people before it was ever
used, and would then have to travel to the second one by some channel
nobody has thought about. No name is asked for either — the signup form
asks the person, and a name an administrator guesses is a name somebody
has to correct.

Two refusals keep the instance administrable: the last administrator
cannot be demoted or deleted, and nobody can delete the account they are
signed in as. Both are enforced on the server; the interface simply does
not draw the buttons on your own row, because a button whose only purpose
is to be refused wastes a click to teach a rule. The last-admin refusal
gets its own error code, because "that already exists" is not what
happened and this is the one refusal a person needs explained.

Deleting an account is the only hard delete in this database, and building
the confirmation is what turned up how wide it goes. `projects.owner_id`
cascades, which is expected. But `tasks.created_by` cascades too — so
removing a colleague deletes every task they ever wrote, including in
projects somebody else owns. The count in the list says so, and the
confirmation says it in words. Changing that to ON DELETE SET NULL, so the
work stays and loses its author, means rebuilding the tasks table and its
FTS triggers: worth doing, not worth doing quietly while adding a screen.
It is written down in the store instead.

Pending invites are listed and can be withdrawn. Only the token's hash is
stored, so a link sent to the wrong address cannot be looked up and
resent — withdrawing it is the only way to stop it before it expires.

Six API tests for the guards and the counts, and two smoke tests: the
whole loop from invite to a second browser creating the account and
appearing in the list as somebody who is not an administrator, and the
absence of buttons on your own row.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

internal/store/invites.go

@@ -136,6 +136,70 @@ func (db *DB) InviteByToken(ctx context.Context, token string) (*Invite, error)
 	return &inv, nil
 }
 
+// PendingInvite is an invite that has been sent and not yet used, as the
+// administrator's list shows it. The token is not here and cannot be: only its
+// hash is stored, so a link that has gone astray is revoked rather than resent.
+type PendingInvite struct {
+	ID          string
+	Email       string
+	ProjectID   string
+	ProjectName string
+	Role        Role
+	InvitedBy   string
+	CreatedAt   time.Time
+	ExpiresAt   time.Time
+}
+
+// ListPendingInvites returns invites that are neither accepted nor expired.
+//
+// Expired ones are left out rather than shown greyed: an invite past its date is
+// not a thing anybody can act on, and a list of them would grow forever. The
+// project name is joined in because an invite with no project means something
+// different — an invitation to the instance itself — and the interface has to be
+// able to say which it is.
+func (db *DB) ListPendingInvites(ctx context.Context) ([]PendingInvite, error) {
+	rows, err := db.QueryContext(ctx, `
+		SELECT i.id, i.email, COALESCE(i.project_id, ''), COALESCE(p.name, ''), i.role,
+		       COALESCE(u.name, ''), i.created_at, i.expires_at
+		FROM invites i
+		LEFT JOIN projects p ON p.id = i.project_id
+		LEFT JOIN users u ON u.id = i.created_by
+		WHERE i.accepted_at IS NULL AND i.expires_at > ?
+		ORDER BY i.created_at DESC`, time.Now().Unix())
+	if err != nil {
+		return nil, err
+	}
+	defer rows.Close()
+
+	out := []PendingInvite{}
+	for rows.Next() {
+		var p PendingInvite
+		var created, expires int64
+		if err := rows.Scan(&p.ID, &p.Email, &p.ProjectID, &p.ProjectName, &p.Role,
+			&p.InvitedBy, &created, &expires); err != nil {
+			return nil, err
+		}
+		p.CreatedAt = time.Unix(created, 0).UTC()
+		p.ExpiresAt = time.Unix(expires, 0).UTC()
+		out = append(out, p)
+	}
+	return out, rows.Err()
+}
+
+// DeleteInvite revokes an invite, which is what makes a link sent to the wrong
+// address recoverable: the token cannot be looked up, so withdrawing it is the
+// only way to stop it working before it expires.
+func (db *DB) DeleteInvite(ctx context.Context, inviteID string) error {
+	res, err := db.ExecContext(ctx, `DELETE FROM invites WHERE id = ?`, inviteID)
+	if err != nil {
+		return err
+	}
+	if n, _ := res.RowsAffected(); n == 0 {
+		return ErrNotFound
+	}
+	return nil
+}
+
 // AcceptInvite marks the invite used and grants the membership it promised, in one
 // transaction. Splitting the two would allow a signup to fail partway and leave a
 // live invite behind, which is a link that still works after it has been used.