A new "Members" tab is rendered between Domains and Settings for
callers whose `my_role` on the app is `app_admin` (owners always;
explicit member-app_admins; admins do not see it — they're only
implicit editors and can't manage memberships).
The tab lets the caller:
- See every explicit member of the app with username, email, instance-
role chip, app-role chip, and joined date. Inactive users render
greyed-out so admins know the row exists.
- Pick a `member`-instance user from a dropdown and grant viewer /
editor / app_admin access. The dropdown is populated from
`/admin/admins` filtered to active members not already on the app.
- Promote / demote / remove existing members via the shared
`ActionMenu` kebab. Removal goes through `ConfirmModal`.
Member-with-app_admin callers see a disabled add form with an
explanatory message — they have authority to manage memberships but
can't browse the user directory (gated on `InstanceManageUsers`),
which is a known phase-3.5 caveat to revisit in a follow-up.
Also extends `RoleChip` with an `appRole` prop and palette for app
roles, and adds an `appMembers` namespace to api.ts mirroring the
`domains` shape.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extends api.ts with the Phase 3.5 wire types (InstanceRole, Scope,
MeDto, AdminDto, ApiKeyDto, MintApiKey*) and the matching apiKeys
namespace. AdminUser in auth.ts now carries instance_role and email,
so layout/store consumers see the role without a separate fetch.
Adds two tiny lib helpers used by the upcoming profile/users pages:
RoleChip.svelte for the colored owner/admin/member pill, and
password-gen.ts for crypto.getRandomValues-backed temporary
passwords used in user-invite + reset-password reveals.
AdminUserRecord stays as a deprecated alias until /admins is
retired in a follow-up commit.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
