Merge remote-tracking branch 'origin/main' into claude/execute-aggregate-execution-context-cukwsp

# Conflicts:
#	packages/services/service-analytics/src/analytics-service.ts
#	packages/services/service-analytics/src/dimension-labels.ts
#	packages/services/service-analytics/src/plugin.ts

Author: claude

.changeset/analytics-execute-aggregate-execution-context.md

@@ -28,19 +28,19 @@ plugin-security has only the analytics layer. This is depth, not a replacement.
   ExecutionContext`. **Custom bridges should forward it** to their engine; the
   built-in auto-bridge does. Purely additive — an existing bridge that ignores
   it keeps working exactly as before.
-- `DimensionLabelDeps.fetchRecordLabels` gains an optional trailing `context`,
-  and `resolveDimensionLabels` an optional trailing `context`.
+- `DimensionLabelDeps.fetchRecordLabels` and `resolveDimensionLabels` each gain
+  an optional trailing `context`, beside the `scope` / `resolveScope` that
+  #3639 added — the same two-belt split as the aggregate path.
 - `BootOptions.analytics` (`@objectstack/verify`) overrides the
   AnalyticsServicePlugin instance, so a gate can boot with the analytics belt
   off and assert the engine-side belt alone still scopes.
 
 **Also fixed on the same seam:**
 
 - `fetchRecordLabels` — the dimension display-label lookup — is row-granular
-  (one row per record, real display names) and ran with neither read scope nor
-  context. Its `ids` are confined to a scoped aggregate's output today, so it
-  leaked nothing, but that was the caller's invariant, not the bridge's. It now
-  ANDs the target object's read scope in and forwards the context.
+  (one row per record, real display names). #3639 gave it the analytics-layer
+  belt (the referenced object's own read scope); it now also carries the
+  context, so the engine scopes the same read independently.
 - `ObjectQLStrategy.generateSql` emitted no `WHERE` at all, so the
   `/analytics/sql` preview read as an unscoped table scan while the real
   aggregate was scoped. It now renders the caller's filters and the read scope.

.changeset/analytics-label-read-scope.md

@@ -0,0 +1,25 @@
+---
+"@objectstack/service-analytics": patch
+---
+
+fix(analytics): scope the dimension-label lookup to the referenced object's RLS (#3602)
+
+When a dataset groups by a `lookup`/`master_detail` dimension, analytics resolves
+the grouped FK ids to the related record's display name via a per-record read
+(`group by id`) dressed as an aggregate. That read carried **no read scope**, so
+it revealed related-record display names whenever the referenced object's RLS is
+stricter than the base object whose rows carry the id — a user could see a name
+the referenced object's own RLS would hide. (Same-object and looser-referenced
+cases were already safe because the ids come from the post-#3597 scoped
+aggregate; this closes the stricter-referenced case.)
+
+The label lookup now applies the **referenced object's own** read scope — bound
+to the request via the same `getReadScope` provider the aggregate path uses,
+composed with `$and` (never key-merge) so it can't be displaced by the id
+predicate. Fail-closed: if that object's scope can't be resolved, the dimension's
+labels are skipped (the raw id renders) rather than fetched unscoped. No behaviour
+change when no read-scope provider is configured.
+
+Internal `DimensionLabelDeps.fetchRecordLabels` gains an optional `scope` argument
+and `resolveDimensionLabels` an optional `resolveScope` resolver; both are
+service-analytics-internal (no spec/contract change).

.changeset/app-metadata-reference-integrity-assessment.md

@@ -0,0 +1,4 @@
+---
+---
+
+Docs-only: development assessment routing the reference-integrity / option-key lint work for app metadata (issue #3583). Releases nothing.

.changeset/better-auth-team-member-count.md

@@ -0,0 +1,43 @@
+---
+"@objectstack/platform-objects": patch
+"@objectstack/plugin-auth": patch
+---
+
+fix(auth): provision the better-auth 1.7 columns `sys_team` / `sys_team_member` / `sys_two_factor` were missing (#3624)
+
+better-auth 1.7.0-rc.1 added fields to three models that the platform objects
+never provisioned and `auth-schema-config.ts` never mapped. Because an unmapped
+field keeps its camelCase name, the adapter emitted columns no table had:
+
+| model | field | column now provisioned |
+|:---|:---|:---|
+| `team` | `memberCount` | `sys_team.member_count` |
+| `teamMember` | `membershipKey` | `sys_team_member.membership_key` |
+| `twoFactor` | `failedVerificationCount` / `lockedUntil` | `sys_two_factor.failed_verification_count` / `locked_until` |
+
+The team pair broke org creation outright. The organization plugin's team
+sub-feature is on by default, so `POST /api/v1/auth/organization/create`
+auto-creates a default team — and that insert died with `table sys_team has no
+column named memberCount` *after* the organization row had already committed.
+Callers got an HTTP 500 on top of a half-created org: a real org row with no
+default team behind it. Every multi-org deployment's create-org flow hit this.
+
+The two-factor pair broke the 2FA lockout path the same way: better-auth
+guard-increments `failedVerificationCount` on each wrong code and stamps
+`lockedUntil` past the threshold, so a wrong code 500'd instead of being
+counted. All four columns are better-auth's own state — provisioned, readable,
+and never written from the ObjectStack side.
+
+Existing environments pick the columns up through the driver's additive schema
+sync; no data migration is needed. `member_count` backfills to 0 and
+better-auth's own `syncTeamMemberCount` reconciles it on the next membership
+change, and `membership_key` stays null on pre-upgrade rows, which better-auth
+tolerates by falling back to the `(team_id, user_id)` pair.
+
+A new drift gate (`better-auth-schema-parity.test.ts`) now asserts that every
+column the installed better-auth version can write exists on the platform
+object backing it, across the auth manager's whole model surface. The ADR-0092
+D7 guard only ever caught *collisions* between our extension fields and
+better-auth's, so a bump that adds a brand-new field passed the build and failed
+at runtime — twice now, counting the 1.7 `oauthAccessToken.authorizationCodeId`
+regression. The next one fails the build instead.

.changeset/export-empty-result-header.md

@@ -0,0 +1,19 @@
+---
+"@objectstack/rest": patch
+---
+
+fix(rest): export emits the projected header row on an empty result set (#3547)
+
+`GET /data/:object/export` wrote a zero-byte file whenever the query matched no
+rows — the header was only ever written alongside the first data chunk. With the
+`getReadableFields` column projection the readable column set is derived from
+schema + context, so it is known even when no rows come back: an empty CSV/xlsx
+export now carries the exact readable header, which also makes it a usable
+import template.
+
+The header is emitted only when the column set is AUTHORITATIVE — the security
+service's readable projection, or an explicit `?fields=` request. When the header
+is schema-derived and the projection was unavailable, the export stays headerless
+as before: the masked-row fallback has no rows to narrow with, and writing the
+full schema header would name FLS-hidden columns. `header=false` still suppresses
+the header in every case.

.changeset/invitation-accepted-host-seam.md

@@ -0,0 +1,20 @@
+---
+"@objectstack/plugin-auth": minor
+---
+
+feat(auth): `onInvitationAccepted` host seam — better-auth's
+`afterAcceptInvitation` forwarded to the host (ADR-0105 D8 prerequisite)
+
+An invitation may carry placement intent (target business unit + positions,
+extension fields on `sys_invitation` per the ADR-0092 whitelist), but there
+was no server-side seam to apply it when the invitation is accepted —
+better-auth's org-plugin models don't fire core `databaseHooks` (framework
+#3541 D8 note).
+
+`AuthManagerConfig.onInvitationAccepted` mirrors `onOrganizationCreated`:
+invoked from `organizationHooks.afterAcceptInvitation` with the mapped ids
+(`invitationId`, `organizationId`, `userId`, `memberId`, `role`, `email`)
+plus the RAW `invitation` / `member` rows so a host reads its own extension
+columns without a second query. Failure-isolated — acceptance never rolls
+back on a side-effect miss; hosts needing effectively-atomic placement
+should make the callback idempotent and reconcile on retry.

.changeset/route-audit-tranche-3-service-mounts.md

@@ -0,0 +1,51 @@
+---
+"@objectstack/service-storage": patch
+"@objectstack/service-i18n": patch
+"@objectstack/client": patch
+---
+
+fix(client,service-i18n): ledger the autonomously-mounted service routes, and repair the two i18n calls that reached nothing (#3636)
+
+Tranche 3 of the #3563 route audit — the last un-audited server surface. The
+dispatcher ledger (#3563) and the REST ledger (#3587) each stop at their own
+package boundary, and two services mount routes outside both: they reach for
+the `http-server` service and register straight on `IHttpServer`, so neither
+`RouteManager` nor `RestServer.getRoutes()` has ever seen them. That left the
+SDK's entire storage surface, plus all of i18n, in the pre-#3563 posture:
+expressed, working, guarded by nothing.
+
+**Ledgers + guards.** `storage-route-ledger.ts` (10 routes) and
+`i18n-route-ledger.ts` (3) sit next to the registrars that mount them, each
+enumerated for real — the registrar runs against a capturing mock
+`IHttpServer` and its registration calls *are* the route set, so a new route
+lands with a reviewed disposition or fails CI. The client half is
+`packages/client/src/service-route-ledger-coverage.test.ts`; ledgers cross the
+boundary as relative source imports, never a service→client package edge.
+
+**Two wire-level 404s fixed.** `i18n.getTranslations` sent
+`/i18n/translations?locale=xx` and `i18n.getFieldLabels` sent
+`/i18n/labels/:object?locale=xx`, while every serving surface — service-i18n's
+mounts, the dispatcher's HTTP mounts, and the `plugin-rest-api.zod.ts`
+contract — mounts only the path form. Neither call could ever be answered.
+Both had carried a green `sdk` row in the dispatcher ledger since tranche 1,
+because that guard asks whether the client *method* exists, not whether it
+speaks a URL anything mounts. The client now sends the path dialect, the same
+resolution #3611 gave `meta.getView`, and a new suite drives the real client
+at a real router so a revert cannot pass quietly.
+
+**One response-shape fix.** service-i18n's success bodies omitted the
+`success` flag that `ObjectStackClient.unwrapResponse` keys on, so the SDK
+returned the raw `{ data: … }` wrapper against that provider while returning
+the declared unwrapped shape against the dispatcher — one method, two shapes,
+decided by which plugin mounted the route. Its three handlers now emit the
+`{ success: true, data }` envelope the `i18n` route group declares. `data` did
+not move, so direct body readers are unaffected.
+
+Storage audited clean: 7 routes SDK-expressed, 3 reviewed `server-only` (the
+browser capability URL objectql stamps into file-field payloads, and the two
+local-driver loopbacks). The chunked-upload family, flagged for triage, turned
+out fully expressed. Both ledgers ratchet `gap` and `mismatch` at zero.
+
+Filed, not fixed: `GET {base}/_local/file/:key` is built by three call sites
+and mounted by none (#3641); the cross-surface URL conformance guard that would
+have caught all of the above mechanically is the capstone (#3642).

.changeset/showcase-action-disabled-specimen.md

@@ -0,0 +1,4 @@
+---
+---
+
+feat(showcase): add the action `disabled`-predicate specimen (`showcase_archive_task`) — greyed until `record.done`, contrasting `visible` (hide) with `disabled` (grey). Examples-only; releases nothing.

.github/workflows/ci.yml

@@ -247,6 +247,35 @@ jobs:
             echo "::endgroup::"
           done
 
+  dogfood-gate:
+    # Stable required-check name for a SHARDED job (#3622 follow-up).
+    #
+    # Branch protection requires the context "Dogfood Regression Gate". Once
+    # the job became a 2-way matrix its checks publish as "Dogfood Regression
+    # Gate (1/2)" / "(2/2)" — the bare context could never appear again, so
+    # EVERY pull request in the repo sat permanently BLOCKED (mergeable, all
+    # checks green, merge button dead). #3622's own comment called for updating
+    # branch protection; keeping the contract HERE instead means a future
+    # shard-count change cannot deadlock the repo a second time.
+    #
+    # `if: always()` + result inspection so a legitimately skipped matrix (the
+    # `filter` job says no core paths changed) still satisfies the gate.
+    name: Dogfood Regression Gate
+    needs: dogfood
+    if: always()
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+    steps:
+      - name: Verify dogfood shard results
+        run: |
+          result="${{ needs.dogfood.result }}"
+          echo "dogfood matrix aggregate result: $result"
+          case "$result" in
+            success|skipped) echo "Dogfood gate satisfied." ;;
+            *) echo "::error::Dogfood shards did not pass (aggregate result: $result)"; exit 1 ;;
+          esac
+
   build-core:
     name: Build Core
     needs: filter