Refactor coderd/chats.go to use 404 errors instead of 403/400 for resource lookups

Commencez dans coderd/chats.go au niveau de chatCostSummary, chatStream et validateCreateChatWorkspaceSelection, puis comparez leur traitement avec le modèle de référence dans coderd/workspaces.go. Modifiez uniquement les erreurs de recherche et d’autorisation propres aux ressources afin qu’elles utilisent des réponses 404, tout en conservant les réponses 403 pour les endpoints d’administration et de configuration du déploiement indiqués. C’est terminé lorsque les cas de ressources spécifiés renvoient 404 sans modifier le comportement d’administration documenté.

Problem

coderd/chats.go uses httpapi.Forbidden() (403) and http.StatusBadRequest (400) in several places where a 404 Not Found should be returned instead. This leaks information about resource existence and authorization state, and is inconsistent with the rest of the codebase which uses httpapi.ResourceNotFound() for these cases.

Scope

Note: Not all httpapi.Forbidden() calls need to change. Documented admin API paths (e.g. deployment config / provider / model config CRUD endpoints) are fine returning 403 Forbidden — those endpoints don't expose whether a specific user-owned resource exists. The refactor should focus on handlers that gate access to specific resources (chats, workspaces, etc.) where returning 403 or 400 leaks that the resource exists.

What Should Change

1. Authorization checks on user-owned resources returning 403 instead of 404

These handlers check authorization against a specific resource and should return 404 to avoid leaking existence:

• chatCostSummary (line ~392): Returns httpapi.Forbidden(rw) when user lacks ActionRead on a specific user's ResourceChat — should be 404
• chatStream → workspace authorization (line ~777): Returns httpapi.Forbidden(rw) when user lacks ActionApplicationConnect or ActionSSH on a specific workspace — should be 404

2. Resource lookup failures returning 400 Bad Request instead of 404

• validateCreateChatWorkspaceSelection (line ~1917): Returns http.StatusBadRequest with message "Workspace not found or you do not have access to this resource" when workspace is not found via httpapi.Is404Error(err) — should be 404
• validateCreateChatWorkspaceSelection (line ~1932): Returns http.StatusBadRequest with the same message when api.Authorize(r, policy.ActionSSH, workspace) fails — should be 404
• chatStream (line ~770): Returns http.StatusBadRequest with "Chat workspace not found." when GetWorkspaceByID fails — should be 404

3. Forbidden calls that are fine as-is (no change needed)

These are documented admin API endpoints where 403 is appropriate — the endpoint path itself is known, and no user-specific resource existence is leaked:

• chatCostUsers (line ~453): ActionRead on ResourceChat (admin endpoint)
• chatUploadFile (line ~2149): ActionCreate on ResourceChat (general permission, not resource-specific)
• chatProvidersList (line ~2663): ActionRead on ResourceDeploymentConfig
• createChatProvider (line ~2773): ActionUpdate on ResourceDeploymentConfig
• updateChatProvider (line ~2851): ActionUpdate on ResourceDeploymentConfig
• deleteChatProvider (line ~2937): ActionUpdate on ResourceDeploymentConfig
• createChatModelConfig (line ~3005): ActionUpdate on ResourceDeploymentConfig
• updateChatModelConfig (line ~3152): ActionUpdate on ResourceDeploymentConfig
• deleteChatModelConfig (line ~3322): ActionUpdate on ResourceDeploymentConfig

Expected Behavior

• Resource lookups that fail (including authz rejections against specific resources) should return 404 Not Found using httpapi.ResourceNotFound(rw), consistent with the pattern used throughout the rest of the codebase (e.g., coderd/workspaces.go)
• This prevents leaking information about whether a resource exists or whether the user lacks permissions
• Admin/deployment-config authorization checks should remain 403 Forbidden

Reference Pattern

The codebase already has the correct pattern in many places in chats.go itself (e.g., provider/model config CRUD using httpapi.Is404Error → httpapi.ResourceNotFound), as well as in other handlers like coderd/workspaces.go.

Created on behalf of @ThomasK33