fix(service-datasource): rebuild the live pool when an update changes connectivity-bearing fields, and make active: false actually disable (#14196)

* fix(service-datasource): rebuild the live pool when an update changes connectivity-bearing fields (#13804)

updateDatasource persisted the merged record and called registerPool, whose
connect-path idempotency guard answered already-registered while the old
driver held the name — so the running pool never followed the record, and
toSummary kept reporting the original connect's retained 'connected'. An
explicitly disabled datasource (active: false) kept serving until restart.

Ruled decision tree: rebuild only when driver/config/external(credentialsRef)/
pool/active actually changed; active: false tears the pool down; on rebuild
failure the OLD pool is kept live under a loudly degraded verdict (never
pool-less). Label-only edits keep the idempotent no-op path: same driver
instance, no churn.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016ZC5rNQj3WEet5HAmmAkMs

* chore: add changeset for #13804

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016ZC5rNQj3WEet5HAmmAkMs

* fix(service-datasource): rule schemaMode into the connectivity-bearing set (#13804)

Contract-review increment on PR #14196 (director-seat conditional PASS,
comment 5494985273). Two changes, exactly as ruled:

1. The changeset for @objectstack/service-datasource moves patch -> minor.
   The diff adds public API — the `datasourceConnectivityChanged` and
   `ConnectivityBearingFields` exports, the public
   `DatasourceConnectionService.reconnect` method, and the published
   `DatasourceAdminServiceConfig.reregisterPool` member — which is additive
   widening = minor by repo convention (#13897 is the same shape). `patch`
   under-reported the surface movement.

2. `schemaMode` joins the connectivity-bearing field set. It was found during
   this card's premise verification and reported as a fork rather than added
   unilaterally; the review ruled it IN in the same stroke. It is really read
   at three sites on the connect path — the `canConnect` policy gate, `toSpec`
   -> `factory.create` (driver construction), and `registerDatasourceDef` (the
   write gate's def) — and it is patchable by `updateDatasource`, so omitting
   it left a schemaMode-only save persisting the new record while all three
   kept the OLD value until restart: a narrower instance of the stale-pool
   defect this card fixes. One comparator line, plus the exported field slice,
   plus one comparator pin. The module docblock now states the resolution
   instead of carrying the fork as an open question.

The label-only reverse control (same driver instance, zero factory calls, zero
evictions) stays green, which is what shows the set widened by exactly one
member rather than into "rebuild on everything".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016ZC5rNQj3WEet5HAmmAkMs

---------

Co-authored-by: Claude <noreply@anthropic.com>

Author: os-steve

.changeset/datasource-update-rebuilds-pool.md

@@ -0,0 +1,45 @@
+---
+"@objectstack/service-datasource": minor
+---
+
+Updating a datasource now rebuilds its live pool when the change actually bears on connectivity — and `active: false` actually takes it out of service
+
+`updateDatasource` persisted the merged record and called `registerPool`, whose
+connect-path idempotency guard answered `already-registered` while the OLD
+driver held the name and returned before building anything. Nothing on the
+update path called `disconnect` first. So reconfiguring a datasource — new
+host, new credentials, new pool settings, `active: false` — changed the stored
+record and left the running connection untouched until process restart, while
+`toSummary` kept reporting the ORIGINAL connect's retained `connected`: a
+successful save describing a pool the record no longer declared. The
+`active: false` corner is security-adjacent — an explicitly disabled data
+plane kept serving.
+
+What "Save" now means for the live pool, decided by what actually changed:
+
+- **A connectivity-bearing field changed** (`driver`, `config`, `external`
+  including `credentialsRef`, `pool`, `schemaMode`, `active` — the set verified
+  against what `attemptConnect` reads into driver construction; a supplied
+  secret counts too, since a rewrap-in-place changes the credential without
+  changing the ref) → the pool is rebuilt in place via the new
+  `DatasourceConnectionService.reconnect`: the old registration is evicted
+  (the #13578 door), a new driver is built FROM THE NEW RECORD through the one
+  shared connect path, and the replaced pool's connection is closed.
+- **The rebuild fails** → the OLD driver instance is restored (with the
+  datasource def eviction removed alongside it), so the datasource is never
+  left pool-less: the previous configuration keeps serving while the retained
+  verdict is loudly degraded and says exactly that. Runtime-admin writes still
+  never brick a running server over a UI action.
+- **`active: false`** → the pool is torn down and the registry stops answering
+  the name — matching every other lifecycle door (`connectDeclared` and boot
+  rehydration never build a pool for a disabled record). `createDatasource`
+  gets the same guard: a datasource born disabled no longer comes up serving.
+- **Nothing connectivity-bearing changed** (a label edit) → the idempotent
+  no-op path, exactly as before: same driver instance, no eviction, no
+  connection churn.
+
+Hosts wiring `DatasourceAdminServiceConfig` directly get the rebuild by
+supplying the new optional `reregisterPool` seam; without it the behaviour is
+unchanged (the idempotent register). The comparison itself is exported as
+`datasourceConnectivityChanged` so a custom seam can ask the same question the
+shipped update path asks.