refactor: task api access

[praveen-bhosle]

Description

• This PR secures task and action APIs and cleans up how user permissions are checked when fetching catalog data.
• First, it adds a new security check (celery_auth_middleware) and a dedicated token (celery_auth_token). This ensures that internal requests coming from background Celery workers originate from the trusted system user, keeping background processes secure.
• Second, it simplifies how permissions are checked for the two most heavily used catalog functions. Instead of having the service layer run repetitive permission checks against Ory Keto for every single item, this change moves those checks up to the FastAPI router level using dependencies. This allows the system to handle authorization upfront (and in batches), stopping redundant database hits before they happen. Other service methods that strictly require deep, custom permission checks remain completely unchanged.

---

What’s Included

• System User Authentication: Introduced a celery_auth_token cookie and celery_auth_middleware to securely authenticate API calls made by asynchronous tasks, actions, and cron workers.
• Endpoint Hardening: Restricted access to /api/v1/task/finish, /api/v1/task/update, and /api/v1/catalog/get/task_ready_to_run exclusively to the system user using the new middleware.
• Targeted Service Layer Refactoring: Removed repetitive access control checks specifically from two core catalog service methods: find_item and find_multiple_items_by_laui. Other service methods that require deep, contextual access verification remain unchanged.
• Declarative Authorization: Implemented upper-level FastAPI router dependencies (Depends) across task, action, and AI route files to handle access validation upfront for these specific lookup paths.

---

Why This Change

1. Dedicated Worker Auth Context: Because Celery workers execute API calls asynchronously on behalf of the user who originally triggered them, the standard user auth_token is already occupied with the initiating user's context. The celery_auth_token separates this logic to prove that the request infrastructure itself is trusted and acting as the system user.
2. Eliminating Redundant Access Queries on Main Lookups: Previously, the low-level catalog service methods find_item and find_multiple_items_by_laui were responsible for enforcing access rights. Because these two specific methods are invoked at incredibly high frequencies across various flows (tasks, actions, AI engines, etc.), they resulted in highly repetitive and redundant permission queries to the Ory Keto database.
3. Optimized Route Dependencies: Moving access validation up to the FastAPI router level for these two pathways centralizes permission enforcement at the API entry point. This allows the API layer to perform clean, optimized batch checks before passing control downstream. This is a targeted optimization; methods that inherently require deep, granular, or conditional access checks still maintain them internally as designed.

---

Acceptance Criteria

• Internal system APIs (/task/finish, /task/update, /catalog/get/task_ready_to_run) successfully reject requests missing a valid celery_auth_token containing system user claims.
• Background Celery workers successfully communicate with these internal endpoints using the new token mechanism without breaking existing execution contexts.
• Catalog service methods find_item and find_multiple_items_by_laui reliably fetch items without internal access-check overhead.
• Router-level dependencies correctly catch and block unauthorized requests across task, action, and AI endpoints utilizing those two specific catalog data paths.

---

How to Test

1. Verify System Endpoints: Attempt to hit /api/v1/task/finish or /api/v1/catalog/get/task_ready_to_run via an external client (e.g., Postman or browser) using a standard user session. Ensure it returns a 401/403 Unauthorized error.
2. Verify Worker Flow: Trigger a background task via Celery and monitor the logs to ensure the worker successfully passes the celery_auth_token and interacts with the protected endpoints.
3. Verify Catalog Access Control: Test task, action, and AI endpoints that retrieve catalog items via find_item or find_multiple_items_by_laui. Verify that:

• Authorized requests still successfully access their respective items.
• Unauthorized requests are blocked immediately at the FastAPI router dependency layer before the service methods are executed.
• Other service layer methods requiring inline checks still independently enforce access logic successfully.

---

Tech Guide

• celery_auth_middleware: Intercepts HTTP requests routed to background-worker-facing endpoints. It extracts the celery_auth_token from incoming cookies and validates that the token claims strictly match the System User's laui.
• Router-Level Performance Guard (Targeted): Moved authorization checks up to the FastAPI route definition files via Depends(...) specifically for flows hitting find_item and find_multiple_items_by_laui. These two service methods now operate under the assumption that data access has already been verified, reducing repeated lookups for high-velocity internal calls. Deep access checks inside other service layer methods remain untouched.

---

User Guide

• N/A (Internal backend refactor and security hardening)

---

Screenshots / Videos

N/A

---

Checklist

• Self-reviewed my code
• Added comments for complex logic
• Added/updated tests
• All tests pass locally
• Have added Tech Guide and User Guide updates

[praveen-bhosle]

The PR is currently incomplete, but I wanted to get early feedback on a specific architectural piece.

@amoghar29, could you please take a look at how the system auth token is being passed throughout the task and action execution flow?

Let me know if you would prefer any changes in that section.