fix: Resolve dataset storage under its owner

[dexters1]

Description

Fixes #4829.

An ACL grantee calling forget() on a shared dataset crashed with UNIQUE constraint failed: dataset_database.dataset_id. Two defects, both fixed inside the dataset-resolution mechanism (single-file core change, no call-site churn):

1. _existing_dataset_database now looks up by dataset_id alone. dataset_id is the table's sole primary key — one row per dataset by schema design since Dataset permissions #869 — so the owner_id filter could only ever turn a hit into a false negative, sending the function into a doomed duplicate INSERT (after already running the graph/vector handlers' create_dataset provisioning for the wrong user).

2. apply_database_context_variables now derives the dataset's owner itself instead of trusting the caller-supplied user_id for storage. The registry row, physical database paths (databases/<owner>/…), and data root always belonged to the owner; previously they were built from whatever id the call site passed, so one wrong call site (forget passed the caller) redirected all of them — the crash above, and on the memory_only paths silently-wrong embedded-DB targets. Now no caller identity can redirect storage.

Deriving the owner reads the dataset row, so entering the context for a nonexistent dataset now fails fast with DatasetNotFoundError — previously it silently provisioned phantom registry rows on SQLite (FK pragma not enabled on that path) or crashed on FK after handler side effects on Postgres.

With storage no longer depending on it, user_id is now optional — it is consulted only by the new opt-in permission gate: pass permission_type="read"/"write"/"delete"/"share" to set_database_global_context_variables to have the caller's grant verified on entry (a permission_type without a user_id is refused). When permission_type is omitted (all current call sites), no permission check is performed here — authorization stays at the API layer exactly as today.

Verification

• Live repro of the issue scenario (owner A, grantee B with ACL grants, B calls forget(data_id, dataset_id)): IntegrityError before → {"status": "success"} after, data record removed, single registry row still owned by A, no stray directories for B.
• cognee/tests/test_delete_permission.py (e2e) extended: grantee forget() end-to-end, plus a direct assertion that get_or_create_dataset_database returns the owner's row to a non-owner.
• New unit tests in test_context_global_variables.py: storage resolves under the owner for a non-owner caller (no permission check without permission_type), and a denied caller with permission_type set is rejected before any storage side effect.
• Full affected unit suites pass (29/29); ruff/pre-commit clean; ty diagnostics unchanged except one more instance of the pre-existing SQLAlchemy Column typing noise.

Notes

• forget.py is untouched relative to dev — the mechanism-level fix makes every call site correct, including the two that passed the caller (forget, cognee_network_visualization).
• Behavior change to be aware of: context entry for a dataset id absent from the datasets table now raises DatasetNotFoundError instead of silently mis-provisioning. An orphaned dataset_database row (possible on SQLite where the FK pragma is off) will surface loudly at migration-runner context entry rather than being processed against a zombie dataset.
• Credit: the primary-key lookup defect and its repro were reported by @BrightMine35 in get_or_create_dataset_database's existence check filters by owner_id, but dataset_id is the table's primary key — false negatives crash /forget (and anything else routed through it) for non-owner users with full ACL grants #4829 (and first fixed in fix: get_or_create_dataset_database's existence check filters by owner_id, but dataset_id is the primary key #4830, alongside @linhongyu510's review catch of the path-redirection consequence — the same conclusion this PR implements at the mechanism level).

DCO Affirmation

I affirm that all code in every commit of this pull request conforms to the terms of the Topoteretes Developer Certificate of Origin.

https://claude.ai/code/session_01QHTS3zLjcskWm1qXDPT1Lx

[github-actions]

minor (correctness verified) — The permission check looks correct: it gates entry before storage is touched (line 91), and the owner resolution on line 227 ensures storage always derives from the dataset's owner, not the caller. Good fix for #4829.

One note: _get_dataset_owner_id has no authorization (intentionally, per its docstring), so any caller can learn who owns any dataset. This is probably acceptable since the permission check happens just above, but worth noting for the security model.