Fix GuestUser serialization

[labkey-adam]

Rationale

Related PR added the guest permissions message by creating an anonymous class. This is unnecessary and fouls up serialization of guest users, so move the method override to the GuestUser class where it belongs.

Related Pull Requests

• Fix misleading permissions message for Guest users in MCP #7894

Tasks 📍

• Claude Code Review
• Code Review @labkey-gokhano
• Manual Testing @labkey-gokhano - See the comments for details. Validated both Guest and User.nobody flows.
• Test Automation Existing test flagged the serialization problem

[labkey-gokhano]

I did the Claude code review as well. This fixes the BVT failure.
Claude raised the previous concern about User.nobody still getting the miss-leading message as opposed to the newly updated one. As I understand User.nobody only comes into picture for unauthenticated request that come in when the "No Guest Account" optional feature is enabled (which is normally disabled by default):

So the full picture:

• "No Guest Account" disabled (the default): getGuestUser() returns User.guest → gets GuestUser's message under Adam's fix. Works fine.
• "No Guest Account" enabled: getGuestUser() returns User.nobody instead → falls through to the base User.getPermissionsRestrictions(), which Adam's fix leaves as the generic "unrestricted permissions" message, regardless of nobody.isGuest() being true.

So yes — flipping that one site setting is the entire trigger. It's not a narrow internal code path; it's the single fork that decides what every unauthenticated request on that site resolves to as its current user.

[labkey-gokhano]

Local validation — PR #7914 (Fix GuestUser serialization)

Built and ran this branch locally (enlistment fully synced to current develop) to validate both the serialization fix and the nobody/"No Guest Account" question above.

Guest scenario (default config): Called the MCP whereAmIWhoAmITalkingTo tool with no API key against a fresh local server. permissionsRestrictions correctly returns "You are connected as a Guest user, which limits your permissions. Provide a valid API key to access more content." with userId: 0 / displayName: "guest" — same behavior as intended, now without the Jackson serialization break.

nobody scenario ("No Guest Account" enabled): Enabled the disableGuestAccount optional feature, then repeated the same unauthenticated MCP flow:

• listContainers() → [] (zero accessible containers)
• setContainer("home") → rejected as an invalid container path
• whereAmIWhoAmITalkingTo called anyway → MCP error -32603: User does not have permission to perform this operation

nobody never reaches getPermissionsRestrictions() here — setContainer (a hard prerequisite for the tool) fails on the permission check first. Confirms there's no code path where nobody would ever see a message, correct or otherwise, so no additional handling is needed for that case.

Conclusion: fix works as intended and doesn't reintroduce a user-facing gap for the no-guest-account case.

[labkey-gokhano]

Re-ran the EHR test 8 of which had failed, not related to this PR per the Test Team.
2nd run came up with only 1 failure, so went ahead and merged.