Fix IDOR vulnerability in saved_views API (Fixes #1761)

[YUVRAJ-SINGH-3178]

Hey! This PR fixes the IDOR vulnerability reported in #1761.

Previously, anyone could mess with other users' saved views by guessing the view ID. To fix this, I completely locked down the saved_views API so everything is strictly scoped to the authenticated user.

Here's what I did:

• Database: Added an owner_id column to the saved_views table and made the UNIQUE constraint apply to (owner_id, name) instead of just globally on the name.
• Migration: Wrote a seamless startup migration in database.py that will upgrade the schema and backfill existing views to a default owner so older setups don't break.
• API Lockdown: Injected the get_current_owner auth dependency into all the routes in saved_views.py and updated every single SQL query (SELECT, INSERT, UPDATE, DELETE) to use WHERE owner_id = ?.

Users can now only touch their own stuff. Let me know if you want any changes!

[utksh1]

This saved-views IDOR branch has merge conflicts and overlaps the active saved-view ownership work. Please rebase onto current main, resolve against the current migration sequence, and add two-owner API regression coverage before re-review.

[utksh1]

This saved-views IDOR branch has merge conflicts and overlaps the active saved-view ownership work. Please rebase onto current main, resolve against the current migration sequence, and add two-owner API regression coverage before re-review.

[YUVRAJ-SINGH-3178]

I've updated the PR with the following fixes:

• Added strict cross-owner isolation tests to verify 403 Forbidden is returned when accessing another owner's view.
• Fixed test auth mocks so they properly test our IDOR protections.
• Resolved migration conflicts with main to keep the DB schema clean.