Recommended workflow for coordinating metadata from different modalities

# User story
Behavior sessions are often run simultaneously with physiology (FIP, ephys). I am trying to understand the recommended workflow for creating metadata for each data modality such that they can be composed automatically. My current understanding is that certain fields in each data modality need to match in order to merge the metadata for the combined asset.
- `acquisition.acquisition_type` this is a string that needs to be the same in both modalities.
- https://github.com/AllenNeuralDynamics/aind-data-schema/blob/71d478b50e64789e28a43eb21e2ddfe06fa66e19/src/aind_data_schema/core/acquisition.py#L288
- My understanding is that in FIP/VR foraging this is being handled by some brittle heuristic, and not a stable workflow (https://github.com/AllenNeuralDynamics/Aind.Experiment.VrForaging-Fip/issues/13)
- `instrument.instrument_id`
- https://aind-data-schema.readthedocs.io/en/latest/instrument.html
- I guess the solution here is that the metadata mapper/extractors for each modality follow the same algorithm for developing instrument ids? I would like a concrete example of how this is supposed to work.
- Are there other fields that need to match?

What is the recommended workflow for how a rig operator ensures this information matches in each modality in a way that supports automated operations at scale. I am having trouble understanding how this is supposed to work. Some possibilities
- each modalities' software requires the rig operator to manually enter information such that these fields match
- we use a to-be-created task launcher that sends these fields to each modalites' software

I believe this issue is related, linking purely for context
- https://github.com/AllenNeuralDynamics/aind-data-schema/issues/1624 (proposed allowing `acquisition_type` to be a list of strings which would solve the composability issue)

# Acceptance criteria
- [ ] A complete list of metadata fields that must match in each modality
- [ ] A recommended workflow for how an rig operator/task launcher is supposed to ensure these fields match across all modalities.

# Sprint Ready Checklist
- [ ] 1. Acceptance criteria defined
- [ ] 2. Team understands acceptance criteria
- [ ] 3. Team has defined solution / steps to satisfy acceptance criteria
- [ ] 4. Acceptance criteria is verifiable / testable
- [ ] 5. External / 3rd Party dependencies identified
- [ ] 6. Ticket is prioritized and sized

# Notes
*Add any helpful notes here.*