Add pending invite flow for collaboration rooms

[rachel-d-07]

Summary

Room owners could add anyone to a collaboration room just by typing a real GitHub username — no invite step, no notification, and no way to accept or decline. The person would wake up as a full member with their username/avatar visible to the whole room and access to chat history they never agreed to join.

Closes #3176

---

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 💥 Breaking change (fix or feature that changes existing behavior)
• 📝 Documentation update
• ♻️ Refactor / code cleanup (no functional change)
• ⚡ Performance improvement
• 🔒 Security fix
• 🧪 Tests only

---

What Changed

• Added a room_invites table (pending / accepted / declined / cancelled) — supabase/migrations/20260712000000_add_room_invites.sql
• src/lib/supabase-rooms.ts: added createRoomInvite, getPendingInvite, getPendingInvitesForUser, getInviteById, acceptRoomInvite, declineRoomInvite, getUserIdByGithubUsername
• src/app/api/rooms/[roomId]/invite/route.ts: now creates a pending invite and fires a notification instead of calling addRoomMember directly
• New endpoints: GET /api/rooms/invites (list my pending invites), POST /api/rooms/invites/[inviteId]/accept, POST /api/rooms/invites/[inviteId]/decline — both accept/decline verify the invite belongs to the requesting user before acting
• src/components/rooms/InviteModal.tsx: copy now says "Invite sent, they'll need to accept" instead of implying instant membership
• src/components/rooms/MembersPanel.tsx: removed the optimistic onMemberAdded call on invite success — the invited user isn't a member yet, so the UI shouldn't show them as one
• New src/components/rooms/PendingInvites.tsx, mounted on src/app/rooms/RoomsListClient.tsx, so invited users can actually see and respond to invites

---

How to Test

1. Log in as User A, create a room, invite User B by GitHub username
2. Confirm User B does not appear in the members list, and the modal shows "Invite sent" instead of adding them
3. Check the room_invites table - a row should exist with status = 'pending'
4. Log in as User B (if they've logged into DevTrack before) - confirm a "Pending Room Invites" banner appears on /rooms with Accept/Decline buttons
5. Click Accept - confirm a room_members row is created and the invite flips to status = 'accepted'
6. On a separate invite, click Decline - confirm no room_members row is created and the invite flips to status = 'declined'
7. Try inviting an existing member - still returns the original 'User is already a member' 409
8. Try inviting the same pending username twice - returns 'An invite is already pending for this user' instead of creating a duplicate row

Expected result: No one is ever added to a room without explicitly accepting an invite.

Checklist

• Linked the related issue above
• Self-reviewed my own diff
• No unnecessary console.log, debug code, or commented-out blocks
• npm run lint passes locally
• No TypeScript errors (npm run type-check)
• Added or updated tests where applicable
• Updated documentation / comments if behavior changed

---

Additional Context

If an invited username has never logged into DevTrack, there's no users row yet to attach a notification to — the invite is still created and will show up if/when they log in, it just won't trigger a notification at invite time.

RLS is enabled on the new room_invites table for consistency with the existing collaboration_rooms/room_messages tables, but actual access control happens in the API route / lib layer, matching how the existing room tables are already enforced (all routes use the service-role client, which bypasses RLS).

No automated tests added this repo doesn't appear to have an existing test suite for the rooms feature to extend, so I tested manually per the steps above. Happy to add tests if there's a preferred pattern/framework you'd like me to follow.

[github-actions]

GSSoC Label Checklist 🏷️

@Priyanshu-byte-coder — please apply the appropriate labels before merging:

Difficulty (pick one):

• level:beginner — 20 pts
• level:intermediate — 35 pts
• level:advanced — 55 pts
• level:critical — 80 pts

Quality (optional):

• quality:clean — ×1.2 multiplier
• quality:exceptional — ×1.5 multiplier

Validation (required to score):

• gssoc:approved — counts for points
• gssoc:invalid / gssoc:spam / gssoc:ai-slop — does not score

Type labels (type:*) are auto-detected from files and title. Review and adjust if needed.
Points formula: (difficulty × quality_multiplier) + type_bonus

[Priyanshu-byte-coder]

Thanks for this — the pending-invite flow has since shipped via #3269, which landed the same feature: a room_invitations table (supabase/migrations/20260729041910_add_room_invitations.sql), invite/accept/decline endpoints, and a PendingInvitations.tsx panel. Inviting someone now creates a pending invitation instead of adding them to the room directly, which is exactly what this PR set out to fix.

Closing as superseded rather than as a problem with the work — your version was a reasonable design, it just arrived alongside another that got there first. If you spot gaps in what shipped (the decline path and the list-my-invites endpoint are the thinnest parts), a follow-up PR against the current code would be very welcome.

Sorry it sat here long enough for that to happen.