feat(sample): control sample_type with enum_sample_type vocabulary

[JoshuaHarris391]

Implements §2A and §3.5 of the proteomics/metabolomics implementation spec. This is the first of two PRs; the additive proteomics/metabolomics property work follows separately.

What changed

• _definitions.yaml — new enum_sample_type: 42 values covering blood and derivatives, tissue, cell-based material, nucleic acids, protein/peptide, biofluids, organoid/xenograft and extracellular vesicles, plus other and not_reported. A parallel enumDef list pins UBERON / PSI-MS / ChEBI accessions. The enum definition deliberately carries no description of its own — that would compete with the description on the properties that $ref it. Researcher-facing guidance lives on the property, which is what the dictionary UI shows.
• sample.yaml and qc_file.yaml — sample_type changes from free-text type: string to $ref: _definitions.yaml#/enum_sample_type, with the vocabulary guidance in the property description. qc_file holds a denormalised copy of the sample block, so both were converted to keep the vocabulary consistent.
• _settings.yaml — dictionary version 1.1.6 → 1.2.0.

Changes were made in test_dict, bundled, validated, then mirrored to prod_dict via copy_to_prod.sh. The two folders are byte-identical.

Validation

All run under poetry run (the bare gen3schemadev on PATH is a pyenv shim at 2.3.5; this repo pins 2.6.1):

poetry run gen3schemadev bundle -i dictionary/test_dict -f dictionary/test_dict/acdc_schema.json
poetry run gen3schemadev validate -y dictionary/test_dict          # exit 0
poetry run gen3schemadev validate -b dictionary/test_dict/acdc_schema.json   # exit 0

Every node reports SUCCESS, no failures. In the bundle, enum_sample_type resolves to exactly {enum, enumDef} with 42 parallel entries and no description, and sample_type on both nodes matches the shape of the existing sample_in_preservation. No required, links, uniqueKeys or systemProperties were touched.

Migration risk — please read before deploying

This is the only non-additive change in the whole spec. Any existing sample_type value in the deployed commons that is not in the enum will fail validation on re-submission. Existing values need mapping first, e.g. "Whole Blood" → whole_blood, "Frozen Blood" → whole_blood plus the existing sample_in_preservation field. The other / not_reported values limit breakage. No live records exist in this repo, so this is a sheepdog deployment concern rather than a repo one.

Worth a look during review

The spec flagged several accessions as needing confirmation in OLS4 before deploying, and they are carried through as-is with inline comments marking them: leukocytes and peripheral_blood_mononuclear_cells (cell-level, CL may be more precise), ascites_fluid, organoid, xenograft, and the two exosome values. These render in the dictionary viewer, so they are worth eyeballing.

Pre-existing, not touched here

Three definitions in _definitions.yaml still carry their own description and have the same $ref-sibling conflict this PR avoids: enum_omics_type, release_state, and data_bundle_state. Left alone to keep this PR scoped, but they are worth a follow-up cleanup.