Merge remote-tracking branch 'origin/main' into feat/types-spec15-ui-reexports

# Conflicts:
#	packages/plugin-view/package.json
#	pnpm-lock.yaml

Author: claude

.changeset/adapt-atomic-publish-and-honest-discovery.md

@@ -0,0 +1,6 @@
+---
+"@object-ui/react": minor
+"@object-ui/app-shell": minor
+---
+
+Adapt to framework 15.1: (1) ADR-0067 D2 all-or-nothing publishes — `formatPublishFailures` renders a rolled-back batch as ONE banner anchored on the causal item (`batch_aborted` entries are summarized, not listed as parallel errors); PackagesPage says "rolled back because X" instead of "{n} failed"; the AI chat publish toast surfaces the real reason instead of a bare count. Pre-15.1 partial-publish responses keep their per-item rendering. (2) ADR-0076 D12 honest discovery — `DiscoveryServiceStatus` gains `handlerReady` + `degraded`/`stub` statuses, new backward-tolerant `isServiceUsable()` helper (absent fields keep the pre-15.1 default; `stub`/`handlerReady:false` gate off; `degraded` stays usable), consumed by `isAuthEnabled`/`isAiEnabled` and `ConditionalAuthWrapper`.

.changeset/adr-0057-ai-usage-indicator.md

@@ -0,0 +1,12 @@
+---
+'@object-ui/plugin-chatbot': patch
+'@object-ui/app-shell': patch
+---
+
+Plan-card approval gives immediate in-card feedback (#2627): clicking
+"Build it" flips the clicked card to a spinning "Building…" badge right away
+(the approval's chat-level effects land at the bottom of the thread, outside
+the viewport, so the card looked untouched for ~10s and users double-clicked).
+The durable Built state still derives from the message stream; an approval
+that never left the client (rate limit / offline) rolls the badge back so the
+button returns. New `planBuildingLabel` prop (AiChatPage passes zh).

.changeset/adr-0085-pr4-remove-legacy-detail-renderer.md

@@ -0,0 +1,17 @@
+---
+"@object-ui/react": patch
+"@object-ui/plugin-detail": patch
+"@object-ui/app-shell": patch
+---
+
+fix(detail): show the "Locked for approval" band on request-tracked backends (objectui#2618)
+
+The DetailView approval-lock band keyed only off the record's own
+`approval_status` field, so it never rendered on backends that track the lock
+via an open approval request and never materialize that field — even though
+the lock was real (writes rejected with `RECORD_LOCKED`). The record-level
+`InlineEditContext` now carries the host's `locked`/`lockedReason` signal
+(the same dual-source `approvalLocked` that already gates `canEdit` in
+`RecordDetailView`), and the band renders from it while keeping `DetailView`
+DataSource-agnostic. Also backfills the approval-lock strings into the detail
+translation defaults so a bare DetailView shows the label, not the raw i18n key.