Expose organization details and email updates

[doobneek]

Supersedes #176.

Summary

• require authentication for direct organization reads
• validate and normalize organization email on create and update
• exclude organization email from public organization and location payloads
• add regression tests for email validation and public/private organization serialization

[github-actions]

Cannot safely approve due to a privacy/access-control regression: organization email can be fetched without authorization via the new organization detail endpoint.

Blocking issues

• Privacy/access-control issue: GET /organizations/:organizationId is publicly reachable (only getUser middleware) and returns full Organization via findByPk, including email (src/routes.js, src/controllers/organizations.js). The new test explicitly validates unauthenticated email exposure (test/integration/get-organizations.test.js). This is a blocking PII exposure risk.

[github-actions]

The PR correctly removes organization emails from public list/location payloads, but it introduces a new endpoint that appears to re-expose email without clear authorization guarantees.

Blocking issues

• Potential privacy/access-control regression: GET /organizations/:organizationId (added in src/routes.js and implemented in src/controllers/organizations.js) returns the full organization record including email, but it is not protected by dataEntryAuth or any organization-level authorization check. If getUser is optional/permissive in this codebase, this enables email harvesting by ID enumeration.
• Missing risky auth tests: there are no integration tests asserting unauthenticated/unauthorized behavior for GET /organizations/:organizationId (e.g., 401/403 expectations). Given this endpoint returns previously-hidden PII (email), auth behavior must be explicitly tested before approval.

[github-actions]

Not safe to approve as-is due to an access-control gap introduced around organization email updates.

Blocking issues

• High severity (auth/integrity): PATCH /organizations/:organizationId now allows updating email (src/controllers/organizations.js), but the route still has no organization-level authorization check (src/routes.js uses only getUser + dataEntryAuth). In production, any authenticated user can modify any organization’s private contact email.
• Risky logic lacks protective tests: new tests cover email format/trim behavior, but there is no integration test asserting unauthorized users cannot update another organization’s email (or organization record) via PATCH /organizations/:organizationId.

Done

[doobneek]

Addressed all bot comments in the current head commit.

• direct organization reads now require org-member/admin authorization in the controller
• organization updates now require the same org-member/admin authorization
• integration tests now cover 401/403/200 cases for both GET and PATCH
• email validation/normalization and public payload redaction remain in place

Addressed in commits 6016f86 and a93fd8f: organization detail and update endpoints now enforce org-member/admin authorization, and GET/PATCH auth regression tests were added.