feat(owletto-backend): gate $member list to members, emails to admins

[buremba]

Summary

• Tightens the public-workspace access policy so PII in the `$member` entity doesn't leak:
  • Non-members of a public org can no longer list or fetch individual members. `manage_entity list/get entity_type=$member` and `resolve_path` both error out with a "join the workspace" message instead of returning sanitized rows.
  • Regular members see the full list but without the `email` field — non-PII metadata (status, role, display_name, …) still renders so the list page has useful columns.
  • Admin/owner callers continue to see everything, including emails.
• Threads `memberRole` through `ToolContext` so handlers can apply the policy without a separate DB lookup.
• Adds an integration test covering all four roles (anonymous, authed non-member, regular member, admin).

Pairs with owletto-web#15, which ships the client-side gate + a sticky "Join" bar so the UI never issues these calls as a non-member. This parent PR will get a follow-up submodule-pointer bump once #15 merges.

Why now

PR #296 added self-serve joining for public orgs and sanitized `/public/` REST endpoints, but `manage_entity list` is marked publicly readable at the tool layer (see `auth/tool-access.ts` PUBLIC_READ_ACTIONS). That path bypasses the `/public/` allow-list and returns raw `metadata`, which for `$member` entities includes the user's email.

Test plan

• `packages/owletto-backend && bun test src/tests/integration/entities/member-email-redaction.test.ts` covers the four role cases.
• Smoke test on a public workspace via the REST proxy:
  • anonymous `POST /api/{slug}/manage_entity {action:list, entity_type:$member}` → 400 with "only visible to members"
  • authenticated non-member → same 400
  • regular member → 200, no email in metadata
  • owner/admin → 200, email present
• `GET /{owner}/$member/{name}` via the web app resolves as a non-member → backend rejects; as a member → email field missing; as owner → email present.

[chatgpt-codex-connector]

💡 Codex Review

lobu/packages/owletto-backend/src/tools/admin/manage_entity.ts

Lines 722 to 726 in af31379

	args.entity_type
	? sql`SELECT metadata_schema FROM entity_types WHERE slug = ${args.entity_type} AND organization_id = ${ctx.organizationId} AND deleted_at IS NULL LIMIT 1`.then(
	(r) => r[0] ?? null
	)
	: Promise.resolve(null),

Load $member schema when redacting emails in mixed lists

Email redaction depends on the $member schema (to find the field marked x-email), but this code only fetches metadata_schema when args.entity_type is set. For action: 'list' calls without entity_type, schema becomes null, so redaction falls back to the literal email key and leaks emails for orgs that renamed the member email field (still marked with x-email) to non-admin members.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Enforce member gate on unfiltered manage_entity list

The new guard only rejects non-members when args.entity_type === '$member', so a caller can still run manage_entity { action: 'list' } without entity_type and receive $member rows from listEntities (it only filters by type when a type is provided). In a public workspace this lets anonymous/authenticated non-members continue enumerating members, which bypasses the intended “member list is only visible to members” policy.

Useful? React with 👍 / 👎.