fix(core): preserve account context on key params and harden account detail fallback

- api_get/post/patch_object: stop treating params.key as account-bypass trigger\n- account detail: remove forced key usage, add list/cache fallback path\n- account detail: fix fallback bug that set load_error even when fallback record existed\n- sites detail: pretty-print cfg_json before save\n- docs: clarify key != bypass and add 403 troubleshooting notes

documentation/BOOTSTRAP__AI_Agent_Quickstart.md

@@ -206,6 +206,10 @@ x-aether-api-key: <PUBLIC_AE_API_SECRET_KEY>
 x-account-id: <account_id>
 ```
 
+**Do not treat `params.key` as an auth bypass.**
+Only explicit `x-no-account-id: bypass` means "drop account context".
+If `key` is present for business logic, keep `x-account-id` intact.
+
 ### Dexie queries — always use the object ID index, not `.get()`
 All `db_core` (and other module) Dexie tables define their schema with `id` as the first
 field (primary key), followed by the object's string ID (e.g. `person_id`). V3 **never**
@@ -288,6 +292,10 @@ These are real incidents — know them before you start.
    clean of data loads in private modules. See `GUIDE__SvelteKit2_Svelte5_DexieJS.md` →
    "SvelteKit Layout Hierarchy: Security and Execution Order" for the full explanation.
 
+10. **Using query `key` as a proxy for bypass stripped `x-account-id`** — this caused
+   valid account-scoped requests to lose account context and 403. `key` can be a valid
+   endpoint/business param, but it is not equivalent to `x-no-account-id: bypass`.
+
 ---
 
 ## 8. Source Layout (Quick Reference)

documentation/GUIDE__AE_API_V3_for_Frontend.md

@@ -21,6 +21,9 @@ Required for any non-public data (Journals, Badges, Users, etc.).
     *   **Header:** `x-no-account-id: bypass`
 3.  **Token Access**: Provide a **JWT** in the query string.
     *   **Query Param:** `?jwt=<token>`
+4.  **Important Distinction:** A query parameter named `key` is **not** an account-context bypass signal.
+  *   `key` may be used by specific endpoints/business logic, but it must **not** cause the frontend to remove `x-account-id`.
+  *   Only explicit `x-no-account-id: bypass` should strip account context.
 
 > [!CAUTION]
 > **UNSUPPORTED HEADERS:** The header `x-aether-api-token` is **NOT recognized** by the V3 API. If you send it, the backend will treat you as a guest and block access to private data.
@@ -587,3 +590,5 @@ If you receive a 403 on a valid ID:
 2.  Ensure you are sending `x-account-id` and NOT `x-aether-api-token`.
 3.  Verify the record actually belongs to the account ID you are sending.
 4.  Check if the object is marked `public_read: True` in the registry. (Posts and Archive Content allow guest access; Journals and Badges do not).
+5.  Confirm the frontend is not treating `params.key` as an implicit bypass and stripping `x-account-id`.
+6.  If list/search endpoints work but `GET /v3/crud/{obj_type}/{id}` still returns 403, this is likely endpoint-level policy (e.g., requires stronger auth like JWT) rather than a transport/header bug.