Extractor drops fk_target_field_id and semantic_type: type/FK from YAML output

[jfi]

Summary

@metabase/database-metadata extract-table-metadata doesn't emit fk_target_field_id for any field, and doesn't emit semantic_type when its value is type/FK (though it does correctly emit type/PK). Both attributes are explicitly described in core-spec/v1/spec.md.

Reproduction

1. Configure a foreign key in Metabase via the admin UI (any FK on any column with semantic_type: type/FK and a populated fk_target_field_id).
2. curl /api/database/<id>/metadata?include_hidden=true — confirm the response includes the field with "semantic_type":"type/FK" and "fk_target_field_id":<numeric>.
3. npx @metabase/database-metadata extract-table-metadata <that-json> <output-dir>.
4. Open the extracted YAML for the table containing the FK column: neither semantic_type: nor fk_target_field_id: appears.

Reproduced against a current Metabase Enterprise instance with 3 manually-set FKs on the schema in scope. Raw /api/database/<id>/metadata?include_hidden=true returns all three FKs correctly; extracted YAML has none of them.

Expected

Per core-spec/v1/spec.md:

semantic_type | string | No | Business-domain label (e.g., type/PK, type/Email).
fk_target_field_id | array | No | Field FK of the referenced primary-key column, for fields with semantic_type: type/FK.

Both should be emitted when present in the API response. fk_target_field_id should be the natural-key tuple [db_name, schema, table, field, ...nested], not the raw numeric id.

Impact

Anyone using the extractor to maintain a YAML source of truth for their Metabase metadata loses every FK relationship on every sync. We worked around this by injecting both attributes post-extract in our own tooling, resolving the numeric id to the natural-key tuple via the raw JSON.

Version

@metabase/database-metadata latest from npm as of 2026-05-15.