Processing the Camera team wants to perform will probably want an "amplifier" dimension; it seems like a prudent thing to add, since it'll cost essentially nothing even if it goes unused.

There's also an open question of whether to have an amplifier row for every amplifier+detector combination (like the patch-tract relationship) or just every amplifier-instrument combination (with amplifier+detector combinations generated as a cartesian product). I think it's probably better to do the former and just expand it out; that will prepare us later if we want to deal properly with e.g. wavefront sensors that have half the usual number of amplifiers. It's worth noting, though, that like our "detector" dimension, these really represent amplifier slots, not physical amplifiers; they would not be changed if the hardware changes, and hence the database rows should not contain things that might change.

This will be a schema change and should not be done until we have a migration system in place, though it's something that could easily be experimented with now in unstable data repos by changing configuration. I'll link a blocker ticket once I have one.