Refactor packaged index factory - #6584

Read the full diff - all 13 files, including the eight new files under Microsoft/PreIndexed/, the factory rewrite, and the Runtime delta. The form/store split is clean and the invariants I went looking for all hold. Approving.

What I checked, in case it is useful to anyone reading later:

Lock semantics are preserved. PreIndexedFactoryBase::LockExclusive is gone, but PackageStoreBase::Lock keeps the identical shape - TryAcquireNoWait() on the background path, Acquire(progress) otherwise - and FullIndexForm::Update calls store.Lock(progress, isBackground). Remove takes store->Lock(progress) at the factory level. CompositePackageStore::Lock delegates to m_stores.front(), and because the lock name is derived from the source identity rather than the storage mechanism, every store over the same source shares one lock. That is the part that would have been easy to get wrong in a refactor this size, and it did not get got wrong.

Lifetime of AcquiredPackage is sound. Move-only, with a hand-written move-assign that clears other.m_isTemporary and other.Path, so no double-delete. The destructor releases the FileLock before std::filesystem::remove. MarkTemporary is set before the download rather than after, so a partial download is still cleaned up.

What gets persisted is what got validated. Acquire takes the WriteLockedMsixFile lock at validation time and hands it to the store, so there is no window between trust validation and persist. LocalFilePackageStore::Persist stages beside the destination and then renames, with a wil::scope_exit that is .release()d on success.

The composite is symmetric. When CanUseDeployedPackage() is false but the process is still packaged, the deployed store is still added - just second. Combined with Resolve only moving off the primary for a strictly newer version, and Remove clearing every store, I could not construct a case where the non-interactive behavior change orphans an existing deployed index. That was my main concern going in and the design already answers it.

One non-blocking nit: the new files are inconsistent about the anonymous-namespace idiom. DeployedPackageStore.cpp uses a real namespace { }, while FullIndexForm.cpp, LocalFilePackageStore.cpp, and PackageStore.cpp use a named namespace anon { }. Not worth another round on its own - just worth picking one before the next form lands on top of these files.

Noting that mergeable_state is blocked, so this still needs whatever other gate is outstanding. All nine checks on 229181a are green.

Re-read the delta since the approval your last push dismissed. The two cancellation additions look right to me.

LocalFilePackageStore.cpp:135 is the one that matters: that check had gone missing in the move out of PreIndexedPackageSourceFactory.cpp, and I did not catch it the first time through. Walking the four IsCancelledBy sites master had, they are all accounted for now - FullIndexForm.cpp:93, PreIndexedPackageSourceFactory.cpp:112, LocalFilePackageStore.cpp:135, PackageStore.cpp:123 - plus the two new ones. And putting the FullIndexForm.cpp:133 check ahead of the !extracted throw is the right order, so a cancelled extraction does not get reported as missing source data.

One thing is holding up my re-approval: the packaged-process / Interactive SID storage selection that actually fixes #6334 has no coverage in this PR, and the plan on that thread is to pick it up with the test infrastructure work next time. Is there an existing test that exercises that selection today? If the follow-up really is the first time it gets covered, I would rather wait for it than sign off on the part of this change I cannot see tested.