Fix: add auth and owner isolation to saved views API (closes #1743)

[S0412-2007]

Description

Removes a critical BOLA (Broken Object Level Authorization) vulnerability in the saved views API. The /api/v1/saved-views endpoints had no auth dependency and never scoped queries by owner — any caller could list,
rename, overwrite, or delete every user's saved views. The underlying saved_views table didn't even have an owner_id column.

Related Issues

Closes #1743

Type of Change

• Bug fix (non-breaking change which fixes an issue)

How Has This Been Tested?

Ran the existing and newly added tests intesting/backend/unit/test_saved_views.py, including new regression
tests for: unauthenticated requests being rejected, cross-owner list isolation, per-owner name reuse, and blocking cross-owner update/delete by guessing a view id.

Checklist

• My code follows the code style of this project.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have made corresponding changes to the documentation.
• My changes generate no new warnings.

[S0412-2007]

@utksh1 ,
Heads up — the backend-unit check is failing on 4 tests in test_tls_verification.py (TypeError: 'coroutine' object does not support the asynchronous context manager protocol). This looks unrelated to this PR — that file was last touched in #1736, not here, and my saved_views changes pass locally along with the rest of the suite (2307 passed).
Let me know if you'd like me to look into it anyway, or if it's a known flaky test.

This is ready for review whenever you get a chance. Summary of the fix:

• Added the missing require_api_key auth dependency to the saved-views router
• Added an owner_id column (migration 009) and scoped all list/create/update/delete
  queries by owner, matching the require_owned_task pattern already used for tasks
• Per-owner name uniqueness instead of a global unique constraint
• Added regression tests for auth rejection, cross-owner isolation, and per-owner
  name reuse

[utksh1]

The migration scopes saved views, but it still treats X-User-Id as the caller identity. A client with the shared API key can simply set X-User-Id to another known owner, so this does not resolve the BOLA claim. Please derive owner_id from an authenticated principal (or trusted, authenticated upstream identity), and add a regression test showing a client cannot select a different owner merely by changing a request header.

[S0412-2007]

The migration scopes saved views, but it still treats X-User-Id as the caller identity. A client with the shared API key can simply set X-User-Id to another known owner, so this does not resolve the BOLA claim. Please derive owner_id from an authenticated principal (or trusted, authenticated upstream identity), and add a regression test showing a client cannot select a different owner merely by changing a request header.

Ok.. Sure @utksh1 I request you to give me a 2 days time for me to correct it.