feat(widget): merge home widget with its pinned widget

[requilence]

Closes JS-9846. Desktop counterpart of DROID-4467, scoped to the sidebar widget panel.

Problem

When the space homepage points at a real object and that object is also pinned as a widget, the sidebar shows it twice — the standalone home link row at the top of the Pin section, plus the pinned widget itself.

Separately: with a homepage set but zero pinned widgets, the home row disappeared entirely. It renders inside the Pin section's items, and that section was only emitted when pinned.length was non-zero (added in 14114a8 to hide an empty section header — it took the home row down with it).

Links view already merged the two via getWidgetObjects(widgets, isLinksView). This brings Widgets view to parity, keeping the widget rather than flattening it to a link row.

Changes

• U.Space.getHomeObject() / isHomeObject() — the homepage only when it points at a real object. The isOneToOne guard is not redundant with isSystemDashboard: in 1-on-1 spaces getDashboard() returns the chat, whose id is the workspace id, which isSystemDashboard never matches.
• The pinned widget whose target is the homepage renders the red settings/home icon instead of its object icon. It keeps its drag position — no hoisting to the top.
• The standalone WidgetHome row is suppressed when the homepage is pinned.
• The merged widget's context menu gains Change Home, opening the homepage picker as a submenu. U.Menu.dashboardSelect is split into dashboardSelectData() + a thin opener so the picker can be used both as a top-level menu and as a submenu.
• The Pin section now stays alive when the standalone home row is its only content.

Scoped deliberately to the Pin section — a homepage object in My Favorites keeps its plain icon. Links view is untouched.

Review-driven fixes

An Opus review agent caught three things worth calling out:

• 1:1 regression. The first version widened the Pin gate via getWidgetObjects(widgets, true). That flag's withHome branch resolves the homepage with getDashboard(), not getHomeObject(), so in a 1-on-1 space it injects the chat and pinned.length >= 1 becomes unconditional — every 1:1 space would grow a Pin section with a "Chat" row that is hidden today. Replaced with if (pinned.length || (home && !isHomePinned)), which also closes a window where the section could render empty while the home object is still resolving in the widgets root.
• Permissions. The menu opens for anyone with canEdit (writer, admin, owner), but the same control in Space settings requires canModerate — owner/admin only. Both the new item and WidgetHome's pre-existing right-click menu are now canModerate-gated, so the action doesn't appear or disappear for a Writer depending on whether the homepage happens to be pinned.
• Render churn. Calling isHomeObject per widget made every widget observe the whole spaceview record, so any detail write on it (sync status, space order, push settings) re-rendered the entire list — undoing the stable-block/stable-getObject memo caching the sidebar sets up on purpose. The home id is now resolved once by the sidebar and passed down as homeId.

Test plan

• bun run typecheck
• bun run lint — 0 errors; 29 pre-existing warnings, none in the touched files
• Manually verified by @requilence
• Pin the homepage object → standalone row gone, widget shows the red home icon
• Merged widget's menu → Change Home is the first action and opens the picker
• Change home to another object → icon moves, or the standalone row returns if the new home isn't pinned
• Unpin the merged widget → standalone row returns
• Remove every pinned widget with a home still set → home row remains
• Home set to Graph / "No home" → no home icon anywhere, no Change Home
• 1-on-1 space with nothing pinned → no Pin section, no home row (unchanged)
• As a Writer in a shared space → no Change Home on either surface
• Links view → behavior unchanged