[Bug] Desktop 0.13 renders an empty space list when the folder collab has a dangling child ref in the workspace root; web and iOS render correctly

### Bug Description

On a self-hosted AppFlowy Cloud instance, the macOS desktop client renders **no spaces at all** — both the "Workspace" and "Private" sidebar sections are empty — when the folder collab document contains a child reference in the **workspace root's** `relation` array pointing at a view id that is absent from the `views` map.

The AppFlowy Web and iOS clients render the same workspace correctly at the same moment, because their sidebars are built from the REST tree (`GET /api/workspace/{workspace_id}/view/{workspace_id}`), which is served from the relational projection rather than from the collab document.

Everything else in the desktop app keeps working: documents open, breadcrumbs resolve, Favorites renders, search works, and websocket sync is healthy (a single session pulled 409 KB successfully). Only the space list is empty.

Critically, **the desktop client logs nothing at all** when this happens. Searching every file under the desktop profile directory (`log.*`, `log.sync.*`) for the offending view UUID returns zero matches — no error, no warning, no indication of which entry failed to resolve.

A second workspace on the same server has a dangling child reference **deeper in the tree** and renders perfectly. Only a dangling ref in the **root** children appears to be fatal, which suggests the deeper levels already skip unresolvable entries and the root-level build does not.

### How to Reproduce

1. Self-host AppFlowy Cloud.
2. In the workspace folder collab document (`collabs/{workspace_id}/{workspace_id}/encoded_collab.v1.zstd`, a zstd-compressed yrs v1 update), add a UUID to `relation[{workspace_id}]` (the workspace root's children array) that does not exist as a key in the `views` map. In our case this arose organically, apparently from an old import — we did not create it deliberately.
3. Clear the desktop client's cache and launch it.
4. Observe the sidebar: no spaces are listed, under either heading.
5. Open the same workspace in AppFlowy Web or iOS: all spaces render correctly.

Position within the root children array does not matter — we moved the dangling entry to the last position and the desktop still rendered nothing.

### Expected Behavior

An unresolvable entry in a parent's children array should be **skipped**, with the remaining resolvable siblings rendered — matching the behaviour that already appears to apply to deeper levels of the tree.

Additionally, a warning naming the unresolvable view id should be logged.

### Operating System

macOS 26.5.2 (build 25F84), Apple Silicon (arm64)

### AppFlowy Version(s)

Desktop 0.13.0 (broken). iOS 0.13.0 and AppFlowy Web (both render correctly against the same server).

### Screenshots

Sidebar with "Workspace" and "Private" both empty, while a document from within one of those spaces is open and renders fine via breadcrumb navigation.

### Additional Context

**Server-side data is verifiably correct.** After repairing both stores, an authenticated request returns a complete space list:

```
GET /api/workspace//view/?depth=1

root name: 'Moogento'
children: 4
- 'General' is_space=True space_permission=0
- 'Bettahost' is_space=True space_permission=0
- 'SideQuests' is_space=True space_permission=0
- 'Recovered' is_space=True space_permission=0
```

All four carry `space_permission = 0`, which should place them under the "Workspace" heading. Web and iOS render them; macOS desktop renders none — before or after the repair.

**Ruled out during investigation:**

| Hypothesis | Result |
|---|---|
| Corrupt folder structure | No — all views exist, parents exist, children arrays consistent, every space reachable from root |
| Stale local cache | No — cleared repeatedly; it re-materialises from the server and still fails |
| Wrong local profile directory | No — verified the app uses the correct uid profile |
| Websocket / connectivity | No — upgrades succeed, sessions run for minutes, one pull was 409 KB |
| Auth / licensing | No — entitlements include `DesktopAndMobile`; all requests return 200 |
| Server errors | No — zero ERROR/WARN in `appflowy_cloud` throughout |
| Position of the dangling entry | Not positional — moving it to last did not help |

**Related server-side issue:** we could not remove the offending entry through the API, because `page-view` mutations return `HTTP 200 {"code":0,"message":"Operation completed successfully."}` while doing nothing when the target view is unreachable. Filed separately as AppFlowy-IO/AppFlowy-Cloud#1636. That is why the workaround below requires editing the collab document directly.

**Workaround, for anyone hitting this:** decode the folder collab object with a CRDT library, delete the offending entries from the `relation` arrays, re-encode, and upload with `appflowy_cloud` and `appflowy_worker` stopped, then clear the `encode_collab_v1:{ws}` and `af:collab:state:{ws}:{ws}` redis caches. Note that repairing only the relational projection (`af_folder_view`) fixes web and mobile but **not** desktop — the two stores are independent and repairs do not propagate between them.

**Suggested fixes**

1. Skip unresolvable children in the desktop space-list build instead of aborting the whole list.
2. Log a warning naming the unresolvable view id.
3. (Server side, tracked at AppFlowy-IO/AppFlowy-Cloud#1636) Return an error rather than `200 ... "Operation completed successfully"` from `page-view` mutations when the target view does not exist.