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/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.