Expose Canvas project read errors and recover existing records

.project-docs/30-worklog/tasks/20261014-canvas-create-recovery-a72d49e6.md

@@ -12,7 +12,7 @@
 
 ## Scope
 
-- Remove the exact create-dialog description, change the Canvas rail from pale lavender to pale yellow, remove its Gallery entry while preserving Code Gallery, diagnose actual Canvas project creation timeouts, and implement the smallest evidenced safe recovery/fix.
+- Remove the exact create-dialog description, change the Canvas rail from pale lavender to pale yellow, remove its Gallery entry while preserving Code Gallery, diagnose actual Canvas project creation timeouts and apparently missing records, and implement the smallest evidenced safe recovery/fix.
 
 ## Intent And Constraints
 
@@ -89,3 +89,18 @@ Gate result:
 - Same-task narrow steering completed: Canvas Gallery entry is absent; Code chat/settings Gallery remains. Standard typecheck, scoped Sidebar/E2E lint, default full build and independent diff review pass.
 - Final real isolated Electron pair passed: Canvas V2 desktop/compact creation/dialog/draft/plan/history (7.1s) and Code remembered-project/shared-settings chrome (5.1s), total 2 passed/12.7s. Inspected final creation-dialog screenshot with pale-yellow rail, no original description and no Canvas Gallery. Logs/PNG updated in the external task evidence stage. Earlier 81 focused unit tests remain applicable to the unchanged retry/store/dialog implementation.
 - The final continuation source HEAD supersedes ca546c9; both are in this branch. No new actual runtime update or Main restart was performed by this continuation. Authorized coordinator will preserve f1dab live WeChat source and active user work during unified activation.
+
+## Same-task Record Visibility Investigation
+
+- User reports no Canvas works/history in the current temporary app. Official same-task start/status again match Identity. Prior positioning/ADR007/cloud authority/runtime/auth/data-preservation context and scoped peer assessment remain applicable; refreshed all readable peer Scope/Intent/Promotion records. Main35142 is unchanged, pointer still436, actual immutable Renderer f1dab. Primary remains occupied and untouched; ea5d477 changes have not been activated, so they cannot be assumed to cause the current empty display.
+- Native readonly observation shows the original five project names and account alice but central region remains Loading AI Design. Source ImageCanvas prioritizes status-ready/nonempty-list/null-workspace loading over its error state; selectProject catch retains status ready with error/null workspace. This is an evidenced presentation path, not proof that canonical records were removed.
+- Planning Gate Passed for this related diagnosis. Read real authenticated bootstrap and project details without mutation or prompt/media body output; compare server counts with visible selected project and request failures. Repair the smallest evidenced loading/error recovery path if necessary, preserving all actual data/drafts and previous source changes. No delete, recreate, model/generation call or server deployment.
+
+## Record Visibility Outcome And Verification
+
+- Real current Main35142 authenticated readonly bootstrap again failed504/30023ms. A second fresh pointer/Main/Renderer/PPID/profile guard terminated only its NetworkService71263, rebuilt as98782. Main35142 and Renderer35176 were preserved; no real command replay, creation, generation, removal or auth binding. current.json bytes later changed as the peer navigation-icon overlay finalized Renderer d3b0d411 based on WeChat f1dab; this task did not edit the pointer or stable alias and does not claim final pointer byte equality. Main source436 is unchanged.
+- After transport recovery, actual readonly bootstrap200/92ms returned five projects. All canonical details200/106–172ms: 愚公移山1turn/0task/0asset; 精卫填海4/2/2; 秋意浓5/1/1; test3/0/0; alice trip2/0/0. Total15 turns,3 tasks,3 assets. These counts verify records still exist; no prompt or media body was printed. External record-read-receipt.json and record-network-recovery-receipt.json retain minimal evidence.
+- ImageCanvas now renders a selected-project detail error before the ready/null-workspace loading state. Its reconnect calls selectProject for the existing active identity, without mutation; missing bootstrap/selection and explicit bootstrap errors reload bootstrap. Normal loading keeps the shell. Later errors with a loaded Workspace preserve its conversation, works and drafts. README synchronized. This presentation/retry change does not pretend to fix the unproven recurring transport trigger.
+- 89 focused unit tests across4 files passed; standard typecheck, scoped index/page-test/E2E ESLint, complete default build:vite and diff check passed. Updated existing isolated Electron V2 acceptance passed1test/6.9s (test6.5s), including simulated detail504 after project switch, visible error/no misleading empty/loading state, reconnect and canonical conversation/completed-history recovery, plus prior desktop/compact/creation/color/no-Gallery checks. Inspected its error screenshot; logs and screenshots retained in the external task evidence stage. Native app was observed on the user's active Agent editor after recovery, so this task did not navigate away or force reload their work. Source activation and actual Canvas UI check remain the authorized coordinator's unified update step.
+- Sole safe conclusion for the live timeout is that recreating the app-owned Chromium network utility restored authenticated reads twice. The30s Main budget spans token acquisition/refresh, Design fetch and body parsing; no evidence proves a fixed20min expiry/background/HTTP2 cause. Future phase-only diagnostics may distinguish these paths, but no timeout extension, unsafe POST fallback or backend fix was introduced.
+- Independent readonly final index/page-unit/E2E/README diff review passed with no blocker. Existing refreshWorkspace rejection does not itself publish an error; this patch preserves loaded data when the store already has an error and specifically fixes selection-read error visibility. The authoritative merged, pushed and actually activated runtime result will be recorded by the separate authorized coordinator, preserving user work and all peer updates.