docs(workspace_profiles+app_controller): fix 3 unverified claims surfaced by re-audit

Honest report: when re-verifying the 4 commits the user asked about
(d82153c0, f973fb27, 5aa19e59, 237f5725), I found 3 docs claims I
made WITHOUT actually reading the code:

1. f973fb27 guide_workspace_profiles.md activation step 4:
   Claimed 'App._apply_panel_states'. This method does not exist.
   Actual: App._apply_workspace_profile(profile) iterates
   profile.panel_states.items() and setattr on App. See
   src/gui_2.py:844-848.

2. 237f5725 guide_app_controller.md Manager objects paragraph:
   Claimed 'App._post_init at src/gui_2.py:3995'. Actual line: 492
   (off by ~3500 lines; the file was refactored during
   startup_speedup and many earlier-line methods were deleted).

3. 237f5725 guide_app_controller.md closing paragraph:
   Claimed 'AppController.__init__ at src/app_controller.py:778-836'.
   Actual range: 778-1212 (the method body is much longer than I
   assumed; the trailing 800-1212 is locks/io_pool/warmup/manager
   wiring). Note added to explain the long range.

Fixes the wrong claims with line numbers I re-verified via AST.

The structural claims (data structure fields, line numbers of
_validate_collection_dim, _init_vector_store, _LiveGuiHandle,
etc.) WERE all verified and are correct.

docs/guide_app_controller.md

@@ -69,14 +69,14 @@ The actual `__init__` (`src/app_controller.py:778-836`) does the following:
 5. **Warmup manager** — `WarmupManager(self._io_pool, log_to_stderr=log_to_stderr)` with an on-complete callback to stamp `warmup_done_ts`. `defer_warmup=True` defers the actual `start_warmup()` call until the first frame is painted (the desktop GUI pattern; headless mode starts immediately).
 6. **Various flags** — `_warmup_started`, `_pending_fetch_provider`, `_defer_warmup`.
 
-**Manager objects** (`preset_manager`, `persona_manager`, `context_preset_manager`, `tool_preset_manager`, `tool_bias_engine`, `history_manager`, `workspace_manager`, `rag_engine`) are **NOT created in `__init__`**. They are lazy attributes accessed via `__getattr__` and created on first reference (typically from `_load_active_project` at `src/app_controller.py:2150` or from `App._post_init` at `src/gui_2.py:3995`).
+**Manager objects** (`preset_manager`, `persona_manager`, `context_preset_manager`, `tool_preset_manager`, `tool_bias_engine`, `history_manager`, `workspace_manager`, `rag_engine`) are **NOT created in `__init__`**. They are lazy attributes accessed via `__getattr__` and created on first reference (typically from `_load_active_project` at `src/app_controller.py:2150` or from `App._post_init` at `src/gui_2.py:492`).
 
 **Hook API surface** is NOT populated by a `register_hooks` method. The actual flow:
 1. `AppController._init_actions()` (called from `init_state` at `src/app_controller.py:1740`) populates `self._predefined_callbacks` and `self._gettable_fields` registries via module-level handler registration functions.
 2. `src/api_hooks.py:HookHandler.do_GET` / `do_POST` reads from these registries to expose App methods as `/api/gui` `custom_callback` actions.
 3. The `sloppy.py` CLI parses `--enable-test-hooks` and passes it to `HookServer` (a separate class, not the controller).
 
-For the actual init flow, read `src/app_controller.py:778-836` (`__init__`), `:1606` (`_init_actions`), `:1740` (`init_state`), and `:2150` (`_load_active_project`).
+For the actual init flow, read `src/app_controller.py:778-1212` (`__init__`; the long range is mostly `_post_init`-style wiring for the 12 locks, GUI health state, io_pool, warmup manager, and lazy manager defs), `:1606` (`_init_actions`), `:1740` (`init_state`), and `:2150` (`_load_active_project`).
 
 This is the **only** bridge between the GUI's app methods and the external Hook API. If a method is not in `_predefined_callbacks`, external callers cannot invoke it.
 

docs/guide_workspace_profiles.md

@@ -139,7 +139,7 @@ def auto_switch(self, context_id: str) -> bool:
 1. Read the profile from the loaded dict.
 2. Apply `ini_content` via `ImGui.LoadIniSettingsFromMemory(ini_content)`.
 3. Apply `show_windows` to the live windows (hide/show as needed).
-4. Apply `panel_states` to the per-panel settable fields via `App._apply_panel_states`.
+4. Apply `panel_states` to the per-panel settable fields via `App._apply_workspace_profile` (which iterates `profile.panel_states.items()` and `setattr`s on the App — see `src/gui_2.py:844-848`).
 
 Activation is immediate; the next frame renders the new layout. Theme is NOT part of the profile (themes are managed by the separate theme system; see [guide_themes.md](guide_themes.md)).