feat(integrations): CnDetailPage sidebar Object form accepts useRegistry / excludeIntegrations (manifest-driven registry sidebar)

[rubenvdlinde]

Closes the gap found while live-testing the xWiki leaf: a consuming app whose detail sidebar is manifest-driven (CnDetailPage via CnAppRoot's #sidebar slot) couldn't flip that sidebar to registry mode — useRegistry was a CnObjectSidebar prop only, with no path from pages[].config.sidebar. Stacked on #213 → #210 → #209 → #204 → #202 → beta.

What's in this PR

• CnDetailPage — the sidebar Object form (and sidebarProps) now accept useRegistry: boolean + excludeIntegrations: string[]; mergeSidebarSources() merges them and syncSidebarState() pushes them into the injected objectSidebarState (reset when the page is suppressed). The sidebar prop JSDoc documents the new keys, the mutual exclusion with tabs, and the host-app binding requirement.
• app-manifest.schema.json + validateManifest.js — config.sidebar on detail pages may now carry useRegistry / excludeIntegrations; validation rejects a non-boolean useRegistry, non-array / non-string excludeIntegrations, and useRegistry: true together with tabs (mutually exclusive). Schema descriptions updated.
• docs — cn-object-sidebar.md gains a "Registry-driven tabs (useRegistry)" section with the #sidebar-slot binding snippet + a manifest example; cn-detail-page.md's sidebar-config section mentions the new keys; CLAUDE.md grows a CnDetailPage bullet; _generated/CnDetailPage.md regenerated.
• tests — CnDetailPageSidebarConfig.spec.js +4 (pushes into objectSidebarState; defaults; cleared on suppression; sidebarProps fallback); app-manifest.schema.spec.js +4 (accepts both keys; rejects non-boolean useRegistry; rejects useRegistry+tabs; rejects bad excludeIntegrations).

The consuming app still has to bind :use-registry / :exclude-integrations from objectSidebarState onto its #sidebar-slot <CnObjectSidebar> (documented) — same shape as the :tabs / :hidden-tabs binding it already does. That's why my live-test deskdesk rewrite (which only changed App.vue partially) didn't flip the sidebar — this PR makes the manifest path actually work end-to-end.

Test plan

• npx jest → 72 suites, 1040 passing (4 pre-existing failures: CnMapWidget + CnAiChatPanel, unrelated, also red on origin/beta)
• npm run lint — no new errors (7 remaining are pre-existing in useObjectLock.js)
• npm run check:jsdoc → "All 79 components meet their JSDoc baseline"
• node scripts/check-docs.js — only the pre-existing CnAi*/useAi*/default gaps

[WilcoLouwerse]

[CONCERN] Vue 2 reactivity: new keys on provided objectSidebarState may not be reactive

CnDetailPage writes objectSidebarState.useRegistry and objectSidebarState.excludeIntegrations by direct property assignment (lines 211-212, 216-217). In Vue 2, adding new properties to an already-reactive plain object bypasses the observation system — downstream template bindings such as :use-registry="objectSidebarState.useRegistry" on the host's <CnObjectSidebar> will NOT update reactively unless the host pre-declared those keys in its data() before providing the object. The test helper makeState() correctly initialises both fields, confirming the authors know about this, but the component itself provides no guard. Fix: document this requirement prominently in the migration note, OR use Vue.set(this.objectSidebarState, 'useRegistry', value) on first write so the component self-heals.

[WilcoLouwerse]

[CONCERN] sidebarProps fallback for useRegistry / excludeIntegrations is undocumented

The mergeSidebarConfig helper falls back to props.useRegistry (i.e. this.sidebarProps.useRegistry) when the sidebar Object form omits it. The test exercises this code path, but the JSDoc for the sidebarProps prop only lists register, schema, hiddenTabs, title, subtitle — useRegistry and excludeIntegrations are not mentioned. Either update the sidebarProps JSDoc to list the full accepted key set, or explicitly deprecate the sidebarProps path in favour of the Object sidebar form only.

[WilcoLouwerse]

Review

🟡 Concerns (2)

• Vue 2 reactivity: new keys on provided objectSidebarState may not be reactive — src/components/CnDetailPage/CnDetailPage.vue:211
• sidebarProps fallback for useRegistry / excludeIntegrations is undocumented — src/components/CnDetailPage/CnDetailPage.vue:229

🟢 Minor (3)

• No validation warning when excludeIntegrations is set without useRegistry: true (src/utils/validateManifest.js:349)
  excludeIntegrations is validated for type but there is no warning when it is set with useRegistry absent or false. In that case the array is forwarded to CnObjectSidebar where it has no effect. A console.warn in syncSidebarState for this combination would surface the misconfiguration earlier and mirror the style of the existing useRegistry + tabs mutual-exclusion check.
• Nullish coalescing on data.results changes behaviour when results is explicit null (src/components/CnXwikiCard/CnXwikiCard.vue:258)
  The new entity-resolve uses data.results ?? data.items ?? .... The ?? operator treats null as nullish, so { results: null, items: [...] } would pick up items. The previous code (Array.isArray(data.results) === true) returned false for null and fell through to data directly. If any API variant returns results: null as a deliberate 'no results' sentinel, the new code silently changes the resolved entity.
• Docs example assumes CnObjectSidebar already accepts useRegistry / excludeIntegrations props (docs/components/cn-object-sidebar.md:157)
  The new docs example shows :use-registry and :exclude-integrations bound to <CnObjectSidebar>. This PR is stacked on feature/integration-xwiki. If those props were added to CnObjectSidebar in a prior PR in that chain, the example is correct — but the generated docs (docs/components/_generated/CnObjectSidebar.md) were not updated in this PR, making it impossible to verify from the diff alone. Confirm merge order so host-wiring docs never land on master before the CnObjectSidebar prop additions do.

Reviewed by WilcoLouwerse via automated batch review.