fix(coderd): store chat ACL keys as canonical UUIDs - #31037

PATCH /api/v2/chats/{chat}/acl stored user and group IDs as the request spelled them. uuid.Parse accepts uppercase spellings, so such a request passed validation and returned 204, but RBAC matches ACL keys as canonical UUID strings: the share granted nothing, and a deleted role sent with another spelling left the stored entry in place. This PR rekeys both role maps with canonicalACLRoles, as the MCP server config and organization skill ACLs do, and returns 400 when two spellings name one principal.

Releases v2.34.0 through v2.38.0 store keys as sent, so before it applies a request, the handler also deletes stored keys that spell a requested principal's ID in a noncanonical form: a deleted role then removes every spelling, and a read role leaves one canonical entry. Principals that the request does not name keep their stored keys, since rekeying them would grant access that RBAC never enforced.

Why it is safe: a canonical ID maps to itself, so requests with canonical IDs behave as before. The chat project ACL already canonicalizes its keys.

Red tests: TestChatACLNoncanonicalIDs shares a chat with a user and a group by uppercase IDs, checks that the user and a group member can read it, then removes both by uppercase IDs and checks that they cannot. It then writes uppercase user and group keys straight to the database, as older servers stored them. A deleted request with either spelling must leave no stored key, and a read request must leave only the canonical keys, let both readers in, and notify the user. Two new TestChatACLValidation cases send one user ID or one group ID in two spellings and expect a 400. On main:

TestChatACLNoncanonicalIDs: GET /api/v2/chats/<id>: unexpected status code 404: Resource not found or you do not have access to this resource
TestChatACLValidation/DuplicateUserSpellings: An error is expected but got nil.
TestChatACLValidation/DuplicateGroupSpellings: An error is expected but got nil.

With the rekey but without the cleanup (79865b4afc9), each legacy case fails when run on its own:

deleted, canonical spelling: Should be empty, but was map[<UPPERCASE ID>:{[read]}]
deleted, uppercase spelling: Should be empty, but was map[<UPPERCASE ID>:{[read]}]
read: Not equal: expected: database.ChatACL{"<canonical ID>": {[read]}}, actual: database.ChatACL{"<UPPERCASE ID>": {[read]}, "<canonical ID>": {[read]}}

These tests also fail on seven go test -overlay mutants. Each skips the rekey, the duplicate check, or the cleanup for users or for groups, or runs the cleanup after the oldChat snapshot.

Review focus: the maps are rekeyed in place after acl.Validate, which still reports IDs that do not parse, so the role loops below read canonical keys. The cleanup runs before the oldChat snapshot, so the share notification treats a user whose legacy entry granted nothing as newly added. On main, that user is not notified again.

#31016 replaces those loops with applyACLReadRoles. The two merge without conflicts and the merged loops read the rekeyed maps; whichever merges second will merge main first.

Validation: go test ./coderd -run '^(TestChatACLValidation|TestChatACLNoncanonicalIDs)$' -count=1 fails on main and on 79865b4afc9 as above and passes here (9 tests with subtests). Also passing here: go test ./coderd -run '(?i)acl|mcp|skill' -count=1 (65 with subtests), go test ./coderd -run '^(TestChatProjectSharing|TestChatSharingDisabled|TestListChatsSharedScope|TestSharedReaderStreamChat|TestChatFileDownloadURL)$' -count=1 (22), and go test ./enterprise/coderd -run '(?i)acl|mcp|skill|TestEnterpriseAuditLogs' -count=1 (46). A local merge with #31016 passes go test ./coderd -run '^(TestChatACLValidation|TestChatACLNoncanonicalIDs|TestChatACLSharingLifecycle|TestChatProjectSharing)$' -count=1 (16 with subtests). go vet ./coderd/ is clean on both, and the pre-commit hook passed (make gen, formatting, golangci-lint, slim build).

Xum, an AI agent, opened this PR for @ibetitsmike and wrote this description.