compat(preboarded): stop mapping the column phase2 renames to SOURCE_METADATA

[ppavlidis]

phase2 renames INVESTIGATION.PREBOARDED_IDENTIFYING_METADATA to SOURCE_METADATA (mysql V24 / h2 V25, on phase2-acl-migrate), generalizing the payload so it can carry upstream metadata for imported experiments and not only preboarded ones.

INVESTIGATION is single-table inheritance, so the identifyingMetadata property in Investigation.hbm.xml puts the old column name into the SQL generated for any polymorphic Investigation query. Once that migration runs against the database both versions share, this build fails with an unknown-column SQLGrammarException. The failure is at mapping resolution, not row read, so the table currently holding zero preboarded rows does not save us.

Why unmap rather than repoint

Repointing the mapping at SOURCE_METADATA would couple the two changes: this build would be broken until the migration ran, and the currently deployed build broken the moment it did. There is no ordering that avoids a window.

Unmapped, 1.32.x is indifferent to what the column is called, and the migration and any redeploy can happen in either order.

Nothing in 1.32.x reads the value — it is a JSON payload only phase2 consumes; the only reference was the round-trip assertion in the compat test. Mapping it was always beyond the "minimum metadata to avoid the explosion" that #1659 set out to provide.

What is unchanged

The <subclass> declaration, accession and source all stay, so the WrongClassException protection #1659 added still works — a phase2-written preboarded row still materializes correctly under a polymorphic load. The Java accessors are kept so existing call sites compile; they now always read null on a reloaded instance, which is documented on the field.

Test

PreboardedExperimentMappingTest.preboardedRoundTripsThroughHibernate still asserts the polymorphic load and the accession / source round trip. Its identifyingMetadata assertion is inverted: it now asserts the value does not survive persistence, so re-adding the mapping fails the test and the message points at the explanation in Investigation.hbm.xml rather than inviting someone to "fix" it.

Verified green against gemdtest. The other failures in a full run on that branch are the pre-existing environmental set on this machine (POSIX file locks, missing cellranger binary, h5ad transform) and are unrelated.

Note on sequencing

This does not need to land before the migration, which is the point of it. But it should land before anyone runs V24 against a shared gemd, since that is the moment an unpatched 1.32.x starts throwing.