Capture entity schema fields and definitions in entry packages (structured registry export)

[drernie]

Motivation

The v0.18.0 entity-links feature (#143, #390) made entries searchable by the human-readable names of the registry objects they reference. A customer evaluating that feature for external sharing has asked whether packages can also carry the registered field values — the structured metadata that makes a package self-describing without access to the source Benchling tenant ("structured registry export").

Today an entry package contains the ELN entry plus link names; the entity registrations themselves (schema fields, values) are not captured, so a package consumer still has to go back to Benchling to reconstruct an experiment's rationale.

Current state

_enrich_link_names (entry_packager.py) already performs one get_by_id per link, but deliberately trims the response with returning=["name"]. The full record for registry types (custom_entity, dna_sequence, aa_sequence) includes everything the customer is asking for:

• fields — every registered schema field with value and display value
• schema — schema id + name
• registryId, aliases, customFields

So the field values cost zero additional API calls — we are already fetching and discarding them.

Proposed change

1. Capture field values — widen (or drop) the returning filter on the existing per-link fetch and persist the returned record.
2. Capture schema definitions — for each distinct schemaId seen, fetch the entity-schema definition (field types, isRequired, isMulti) from the schemas endpoint. Cacheable per schema id; entries typically reuse a small number of schemas.

Where the data lands

Follow the established rule (see #390): raw facts in the file, curated view in metadata.

• links.json gains the fetched fields / schema / registryId per link — this is Benchling's data, not our inference, so it belongs in the raw archive. Bump schema_version.
• Schema definitions land alongside (e.g. a schemas section keyed by schema id, or a sibling schemas.json).
• The searchable links metadata array in entry.json stays lean ({type, id, name, slug}). Per-entity field values are not promoted into package metadata — that would bloat the Elasticsearch documents, and the external-sharing consumer reads the file, not the search index.

Access gating

Same as name enrichment: the Benchling app must be a registry/project collaborator. On 403 or fetch failure, record the link with no fields captured (generalizes the existing name: null behavior). Never drop a link.

Out of scope

• Entity-as-package / one-package-per-entity (tracked separately, Package Entities #143)
• Bidirectional references (references/{entry_id}.json)
• Promoting field values into searchable metadata

Open questions

• Which types beyond custom_entity / dna_sequence / aa_sequence should be field-enriched first? (Boxes, plates, results tables, protocols are candidates — awaiting customer feedback.)
• Schema-definition cache scope: per-invocation is trivially safe; cross-invocation needs invalidation thought.