Datastore sync surfaces opaque errors from extensions verbatim — no status code or body preview

Summary

When a datastore sync call (pull/push) fails inside a datastore extension, core swamp surfaces whatever error the extension throws with no additional framing. If the extension throws a malformed or non-descriptive error (e.g. an AWS SDK UnknownError whose XML deserializer gave up on an unexpected response body), the user sees a bare stack trace with no hint about what actually went wrong.

Sibling issue filed against the extension itself: https://github.com/systeminit/swamp-extensions/issues/74 (@swamp/s3-datastore should catch and normalize these). This ticket covers the core side of the problem: even with a better-behaved extension, core's sync error-surfacing is thin.

Observed

During swamp model create @swamp/issue-lifecycle ... against an S3 datastore with invalid credentials, core logs:

{"error":"UnknownError","stack":"    at ProtocolLib.getErrorSchemaOrThrowBaseException (...s3.js:13151:63)\n    at AwsRestXmlProtocol3.handleError (...s3.js:14851:65)\n    ..."}

No indication that this was a sync call, which model/operation triggered it, or any response metadata (HTTP status code, request ID) that the SDK did attach to the error object.

Expected

When a sync operation raised by DatastoreSyncService.pullChanged() / pushChanged() (or the coordinator that wraps them) throws, core should enrich the logged error with:

• Which operation was in flight (pull vs push, which extension/type)
• Any standard metadata fields if present on the error object ($metadata.httpStatusCode, $metadata.requestId, Code, name)
• A short preview (first ~200 chars) of error.message if it is longer, or of any body / response fields if exposed by the extension's SDK

That way, even an opaque UnknownError becomes actionable (e.g. "HTTP 403, no parseable body, from @swamp/s3-datastore during pushChanged").

Scope

The fix belongs in core's datastore sync coordinator and/or the call sites that invoke pullChanged/pushChanged — the locations that currently catch sync errors and log them. Those sites should inspect the error for standard SDK metadata fields (duck-typed; no AWS-specific import), add the operation context, and pass a structured log entry rather than JSON.stringify(error).

Out of scope: changing the extension contract to require normalized errors — this is a defensive improvement on core's side that works regardless of how well-behaved the extension is.

Environment

• swamp: 20260206.200442.0-sha
• Platform: macOS (darwin 25.3.0)