Fix: group membership changes didn't invalidate the User cache

routes/group.js's add/removeMember never called User.clearCache(), unlike
the isServiceAccount handling in routes/user.js (which does this
deliberately, with a comment explaining exactly why). isServiceAccount is
derived at User.get() time from app_sso_service_account membership and
cached for 5 minutes -- so adding or removing a user from ANY group via
this route left group-derived state (isServiceAccount, and by extension
anything else that reads memberOf off a cached User) stale for up to 5
minutes.

In production this manifested as a real user's account appearing to
"vanish": users.ejs's People tab filters out anything with
isServiceAccount truthy, so once that user's membership in
app_sso_service_account changed, they'd disappear from the tab anyone
actually looks at for up to 5 minutes -- looking exactly like data loss,
though the account was never touched. Found by investigating a live "lost
users" report: the account had isServiceAccount: 'yes' and was in fact
still fully present, just hidden.

This does not explain how the account came to be a member of
app_sso_service_account in the first place (unresolved -- possibly a
manual/accidental group-membership change via the Groups UI, which has no
guardrail against adding a real person to what's meant to be a marker
group for non-person accounts). It does fix a real correctness gap: any
admin group-membership change now takes effect immediately instead of on
a timer.

Verified against a real LDAP+Redis harness: the new test fails on the
unfixed code (stale isServiceAccount immediately after the PUT) and
passes with the fix. Full suite: 189/191 passing (2 pre-existing skips).

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

nodejs/tests/group.test.js

@@ -151,6 +151,32 @@ describe('Groups — member management', () => {
 		const members = Array.isArray(group.member) ? group.member : [group.member];
 		expect(members.some(dn => dn && dn.includes(MEMBER_UID))).toBe(false);
 	});
+
+	// Regression: adding/removing a member here didn't clear User's LRU
+	// cache (ttl 5 minutes), so isServiceAccount -- derived from
+	// app_sso_service_account membership at GET /api/user/:uid time -- could
+	// stay wrong for up to 5 minutes after the group change. In production
+	// this hid a real person's account from the Users page's "People" tab
+	// (it filters out anything with isServiceAccount) for however long the
+	// stale cache entry lived, which looked exactly like the account had
+	// vanished.
+	test('PUT app_sso_service_account/:uid immediately flips isServiceAccount (no stale cache)', async () => {
+		const added = await request(app)
+			.put(`/api/group/app_sso_service_account/${MEMBER_UID}`)
+			.set('auth-token', token);
+		expect(added.status).toBe(200);
+
+		const afterAdd = await request(app).get(`/api/user/${MEMBER_UID}`).set('auth-token', token);
+		expect(afterAdd.body.results.isServiceAccount).toBeTruthy();
+
+		const removed = await request(app)
+			.delete(`/api/group/app_sso_service_account/${MEMBER_UID}`)
+			.set('auth-token', token);
+		expect(removed.status).toBe(200);
+
+		const afterRemove = await request(app).get(`/api/user/${MEMBER_UID}`).set('auth-token', token);
+		expect(afterRemove.body.results.isServiceAccount).toBeFalsy();
+	});
 });
 
 describe('Groups — owner management', () => {