Guard Jaah-managed EFS from tenant adopt and credential

Security surface (cross-org storage). Run the autonomous security review lane before merge. (a) Evidence: two gaps, deferred in the reports of 6416 (PR #5528) and 6417 (PR #5537), and confirmed in code at develop 930f990cc: 1. A tenant "Use existing" of a file system that a Jaah-managed store records is accepted. That tenant's first `write_policy` then writes a policy holding only its own APs, which drops every other org's AP on the operator EFS. 2. Deleting the operator-plane AWS credential that backs a location store CASCADEs and takes tenant NodeLinks with it. (b) Cause: 1. `apps/api/app/routes/org_shared_store.py:348-352` checks `FILE_SYSTEM_TAKEN` only within `OrgSharedStore.org_id == org_id`. 2. The credential delete path does not check `org_shared_store.credential_id` for a store whose `managed_location IS NOT NULL`. (c) Fix: 1. In `new_existing_store`, refuse with 409 a `file_system_id`+region that any store with `managed_location IS NOT NULL` records. The message names no other org. 2. Refuse with 409 deleting a credential that backs a managed location store, saying "This credential backs Jaah-managed NodeLink storage. Replace it in Settings first." (d) Acceptance (API tests, no AWS): - A tenant adopting the managed FS gets 409, and the managed store's policy AP set is unchanged. - Deleting the backing credential gets 409, and the store and tenant NodeLinks remain. - A tenant adopting its own FS still works. - The security lane verdict is in the PR body. (e) Out of scope: the absorb flow (6417), per-org AP quotas, purge cleanup, and EFS policy semantics. Done means: the tests pass; `./dc check full` green; PR merged to develop; Jaah Deploy succeeded.

Tenant Use-existing of a Jaah-managed FS and deleting its backing credential now 409 (operator-plane checks, API tests). Full gate green, review/security/verifier lanes pass, PR #5543 merged, Jaah Deploy succeeded. Deferred: adopt-vs-save race; non-managed credential cascade.