[DT-4061] Promote study registration asset lists to first-class fields

[otchet-broad]

Base: branch 5 · 20 files, +1227/-16 · Migration: yes (2 changesets, data rewrite) · UI impact: designed to be none — verify

The riskiest PR in the stack, and the only one that rewrites existing data.

DatasetRegistrationSchemaV1.yaml declared assets as client-managed
metadata "preserved and returned as-is by the backend; not
backend-validated". Backend endpoints and dashboard counts came to depend on
individual keys inside it, so that contract no longer held. This promotes the
eight lists the backend reads — models, workspaces, presentations,
publications, clinicalTrials, intellectualProperties, biospecimens,
funding — to top-level registration fields, each stored in its own
study_property row, with schemas for the item types.

Compatibility is the point of the StudyAssets helper. Reads fall back to
the legacy object for a study not yet rewritten, and writes are still
accepted through it, so a client that has not moved to the top-level fields
keeps working. Registration reads and the search index both still return the
full assets object — every promoted list plus whatever unpromoted keys
remain — so no consumer sees a shape change.

Two details deserve review attention. A promoted property that parses is
authoritative even when empty, so a submitter who removed the last asset of a
type does not get it restored from a stale legacy copy. And "provided" means
present, not non-empty: registration reads return each list both top-level
and inside assets, so an edit clearing the top-level list arrives beside
the pre-edit legacy copy, and treating [] as "not provided" would resurrect
what was just removed.

Migration promotes each array-valued key out of assets into its own row,
then strips the promoted keys and drops any assets row left empty. Guarded
to skip non-object and non-array values and to skip a study that already has
the target row.

Rollback hazard: once the strip changeset runs, code from before this
branch can no longer see these lists — they no longer live in assets.
Rolling back the deploy requires restoring the data.

Also corrects IntellectualProperty.filingDate from boolean to string.

Depends on: nothing in branches 1-5 — no code dependency on any of them.
Placed last deliberately, because it is the only data rewrite in the stack and
the hardest to roll back. It can be reordered earlier if that suits review.

---

Where this sits in the DT-4061 stack

otchet-dt-3990-study-ratings-pi-details was too large to review meaningfully
(95 files, +8168), so it was split into eight PRs. This PR targets otchet-dt-4061-study-recommendations,
not develop, so its diff shows only its own work.

#	Branch	Base
1	otchet-dt-4061-study-visibility-authz	develop
1b	otchet-dt-4061-study-patch-ownership	otchet-dt-4061-study-visibility-authz
2	otchet-dt-4061-study-pi-details	otchet-dt-4061-study-visibility-authz
3	otchet-dt-4061-study-comments	otchet-dt-4061-study-pi-details
4	otchet-dt-4061-study-dar-metrics	otchet-dt-4061-study-comments
5	otchet-dt-4061-study-recommendations	otchet-dt-4061-study-dar-metrics
6	otchet-dt-4061-study-asset-fields ← this PR	otchet-dt-4061-study-recommendations
7	otchet-dt-4061-study-asset-endpoints	otchet-dt-4061-study-asset-fields

Branch 1b is a sibling rather than a link in the chain: nothing depends on it,
so it can be held or dropped without blocking the others. Land the numbered
chain in order — merging out of order, or squash-merging, will require rebasing
the descendants.

The split is verified lossless: branch 7 plus 1b reproduces the original branch
exactly, apart from five scripts/verify-study-*.sh helper scripts that were
dropped at the author's request. ./mvnw test-compile passes on each branch
independently.

🤖 Generated with Claude Code

[kevinmarete]

The promotion skips a key when its value is not an array, but the strip changeset removes that key regardless. For example, an existing unvalidated assets value containing "models": "custom-value" will lose that data. Please retain wrong-shaped values unless a value was successfully promoted or an authoritative first-class property already exists, and add a migration test for a JSON object containing a promoted-name key with a non-array value.

[kevinmarete]

Here is a finding:

The runtime compatibility handling can discard legacy values that the migration deliberately preserves.

For example, the migration retains an unvalidated value such as "models": "custom-value" because it cannot promote it to an array. However, StudyAssets.assemble() removes the legacy models key and restores it only when it resolves to a nonempty list, so the value disappears from registration and search responses. On the next registration write, promotedValue() ignores the non-collection value while stripPromoted() removes it, deleting the only stored copy.

Please preserve wrong-shaped promoted-name values through both reads and writes, or explicitly migrate/reject them without silently losing data. Add a round-trip test covering a legacy assets object with a non-array value under a promoted key.

[kevinmarete]

One finding:

promotedValue() performs a case-sensitive lookup with assets.get(key), while stripPromoted() removes list-valued keys using equalsIgnoreCase. Consequently, a legacy value such as "Models": [...] is not promoted but is removed from assets, losing the data during a registration update. Please use the same case-insensitive lookup in both paths and add a round-trip test for a differently cased promoted key.