Update repository methods for versioning PR1

[oilagh]

Description

First PR that simply adds request versioning column to supabase thru migration & modifies existing request enpoints to fetch the request with the latest version (in case of same ids)

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• [ X ] New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactoring (code improvement without changing functionality)
• Documentation update
• Configuration/infrastructure change
• Performance improvement
• Test coverage improvement

Related Issue(s)

Closes #
Related to # #108

What Changed?

• Essentially just update find request, find requests, and inert request at the repo level to change the way it accesses records from the DB
• Add a new column request_version to DB

Testing & Validation

I only modified existing tests for our requests endpoints and made sure they passed.

How this was tested

1. Unit tests

Screenshots/Recordings

Unfinished Work & Known Issues

• None, this PR is complete and production-ready
• [ X ] The following items are intentionally deferred:
  • in future PRs need to add new PATCH/PUT for creating a new request with the same ID but updated request_version

  • ---

  • ---

Notes & Nuances

• ---

• ---

Pre-Merge Checklist

Code Quality

• Code follows the project's style guidelines and conventions
• Self-review completed (I've reviewed my own code for obvious issues)
• No debugging code, console logs, or commented-out code left behind
• No merge conflicts with the base branch
• Meaningful commit messages that explain the "why"

Testing & CI

• All CI checks are passing
• All new and existing tests pass locally
• Test coverage hasn't decreased (or decrease is justified)
• Linting passes without errors

Documentation

• Code is self-documenting or includes helpful comments for complex logic
• API documentation updated (if backend endpoints changed)
• Type definitions are accurate and up-to-date

Reviewer Notes

• Areas needing extra attention: ...
• Questions for reviewers: ...

[Dao-Ho]

Left some thoughts on this, overall you nailed the essence of what we want to do 🔥 🔥 Would love to hear what you think though

[Dao-Ho]

I'd move this migration to a separate pr and merge/apply the migration before we actually update the query.

[Dao-Ho]

What is the difference between request_version and updated_at? 🤔 Maybe we don't need both

Also a couple of ways I think we can interpret/design the storage of this data. We can either maintain the original created_at across all versions that we insert, or we could handle that in our find query (fetch the latest request but return the request_version of the first version, which we'll have to do for all queries fetching requests). I'll leave this design decision up to you.