bug: GET /v1/sessions/{id} leaks tenant existence to cross-tenant users

[OneStepAt4time]

Summary

When a user on one tenant requests a session belonging to another tenant, the error message explicitly states "session belongs to another tenant" instead of returning a generic 404. This confirms to an attacker that the session ID exists and is in a different tenant.

Reproduction

1. Create an operator key on tenant default
2. Get a session ID from _system tenant (e.g. from admin key)
3. Call GET /v1/sessions/{system-session-id} with the operator key

Expected

{"code": "NOT_FOUND", "message": "Session not found"}

Actual

{"code": "FORBIDDEN", "message": "Forbidden: session belongs to another tenant"}

Impact

• Confirms session ID existence to unauthorized users
• Reveals multi-tenant architecture to attackers
• Write endpoints (send, kill, delete) correctly return "Session not found" — inconsistent

Fix

Return same NOT_FOUND response for cross-tenant reads as write endpoints do.

Version

Aegis v0.6.7-preview.1

Severity

Low — requires authentication and valid session UUID, but inconsistent with write endpoint behavior

[OneStepAt4time]

Fixed in #3375 — cross-tenant session access now returns 404 instead of 403.