Ingest_v2 MergePipeline (Packager, Uploader) inconsistency after index update

1. Packager
   If you use the tags/partition feature, after a doc_mapping update that adds new fields and shifts the initial positions of fields responsible for tags/partitions, the split metadata will become corrupted (as described in #5866). This happens because the saved NamedField does not respect the schema of the split. For the old MergePipeline, this means that all new splits will not be found via tag-based search. For a recreated pipeline, it could drop existing tags if the new position of the tag field points to a field in the old index that contains > MAX_VALUES_PER_TAG_FIELD terms.

2. Uploader
   After #5543, the Uploader depends on the RetentionPolicy. However, updating the policy does not update the pipelines. For the IndexingPipeline, this can be done easily by patching indexing_params_fingerprint(), but it does not affect the MergePipeline since the old one may still be used. This is not critical, but leads to the same noisy errors as in the original issue if you set new_retention < maturation_period < old_retention.

P.S. It seems there is a redundant lock on the indexes table in the Postgres metastore's publish_splits() with Ingest_v2, since index_metadata is not updated.

Start by tracing the Ingest_v2 MergePipeline's Packager and Uploader, then inspect IndexingPipeline and indexing_params_fingerprint() for the retention-policy behavior described. Review the Postgres metastore's publish_splits() as a separate lead. Done means index updates preserve split metadata and retention changes no longer produce the reported noisy errors, with the lock behavior clarified.