…om fields

Marketplace-app / extension references embedded in entry DATA (e.g. an
`image_presets` value's `metadata.extension_uid`) are stack-scoped and must
be remapped to the destination app's extension_uid during import. The remap
in `lookupAssets` (`findAssetIdsFromJsonCustomFields`) only walked top-level
schema fields, so any `is_asset` JSON custom field nested inside a
group / global_field / blocks was skipped.

Consequences of the miss:
- the entry kept the source app's extension_uid, leaving an orphaned
  reference on the destination stack; and
- on a subsequent import the audit flagged that UID as a missing reference
  and stripped the whole field (silent data loss of image-preset configs).

Replace the flat `ctSchema.map` with a recursive walk
(`remapJsonCustomFieldExtensionUids`) that follows the entry-data shape
through group / global_field / blocks and handles multiple-valued fields,
remapping `metadata.extension_uid` (and the schema field's extension_uid)
via the marketplace_apps mapping.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…borting the module

`updateAppsConfig` called `nodeCrypto.decrypt(configuration)` inline as the
argument to `.setConfiguration(...)` / `.setServerConfig(...)`. A bad-decrypt
(e.g. ERR_OSSL_BAD_DECRYPT when an app's exported `configuration` was
encrypted with a different key) therefore threw synchronously — outside the
promise chain's `.catch` — and propagated up through `installApps` (which
re-throws), aborting the entire marketplace-apps module.

Because the module aborted, `mapper/marketplace_apps/uid-mapping.json` was
never written. Global fields / content types (and entry data) then had no
marketplace extension mapping to remap against, so their imports failed with
"extension_uid ... does not exist in destination stack".

Fix: decrypt inside a try/catch for both configuration and server_configuration.
On failure, log a warning and skip only that app's config push; the app stays
installed and its extension_uid mapping is still recorded, so downstream
GF/CT/entry remapping works and the uid-mapping file is written.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

… fix/dx-7312-entry-data-extension-uid-remap

Address PR review on the entry-data remap:

- Replace the schema-driven walker with `remapEntryMetadataExtensionUids`, a
  schema-independent deep walk of the entry data that remaps any
  `metadata.extension_uid` via the marketplace_apps mapping. This is robust to
  is_asset custom fields nested in group / global_field / blocks AND to
  content-type schemas that carry a reference-only global_field stub (no
  expanded `schema`, e.g. from query-export), which the previous schema-driven
  walk would silently skip.
- Run it once, unconditionally, after `find()` (idempotent — already-mapped
  UIDs are no-ops).
- Guard `find()` against a missing schema so a global_field stub no longer
  throws while collecting assets.
- Keep the schema field `extension_uid` remap for parity.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Address PR review on the entry-data remap:

- Replace the schema-driven walker with `remapEntryMetadataExtensionUids`, a
  schema-independent deep walk of the entry data that remaps any
  `metadata.extension_uid` via the marketplace_apps mapping. This is robust to
  is_asset custom fields nested in group / global_field / blocks AND to
  content-type schemas that carry a reference-only global_field stub (no
  expanded `schema`, e.g. from query-export), which the previous schema-driven
  walk would silently skip.
- Run it once, unconditionally, after `find()` (idempotent — already-mapped
  UIDs are no-ops).
- Guard `find()` against a missing schema so a global_field stub no longer
  throws while collecting assets.
- Keep the schema field `extension_uid` remap for parity.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>