feat: add invitation link limits

.trellis/tasks/07-03-invite-link-limits/implement.md

@@ -0,0 +1,42 @@
+# Invite Link Limits Implementation Plan
+
+## Checklist
+
+1. Update Trellis planning artifacts and get approval to start implementation.
+2. Load pre-development specs with `trellis-before-dev`.
+3. Update `modules/core/server/schema.ts`:
+   - Add `maxUses` and `usedCount` integer columns to `organizationInvitations`.
+4. Generate or add the Drizzle migration for the new columns.
+5. Update shared invitation types and row mappers:
+   - `modules/core/types.ts`
+   - `modules/core/server/settings.ts`
+   - `modules/core/server/store.ts`
+6. Update invitation creation API:
+   - Parse `validityDays` and `maxUses`.
+   - Validate positive integer ranges.
+   - Persist `expiresAt`, `maxUses`, and `usedCount`.
+7. Update invitation registration flow:
+   - Reject exhausted links.
+   - Increment usage inside the transaction.
+   - Mark status accepted only when `usedCount` reaches `maxUses`.
+   - Guard concurrent consumption with an update predicate.
+8. Update frontend:
+   - Add validity and maximum-use controls to `OrganizationInviteDialog`.
+   - Display usage count in `OrganizationDetailClient`.
+   - Update invitation explanatory text where it still says invitations are one-time only.
+9. Run validation:
+   - `pnpm lint`
+   - `pnpm type-check`
+   - `pnpm test` if tests are relevant or fast enough after type changes.
+   - `pnpm build` if lint/type-check pass.
+
+## Risk Points
+
+- Concurrent registrations could over-consume an invite unless the update predicate checks `used_count < max_uses`.
+- Existing accepted invitations should remain unusable regardless of migrated counter defaults.
+- Frontend numeric inputs submit strings, so backend parsing must not trust the client.
+
+## Rollback Points
+
+- Before migration: schema/API/UI changes can be reverted together.
+- After migration: reverting code while keeping columns is safe because defaults preserve one-use invite behavior.