Configured prebuilt wheels end up in a different directory in build commands #1440

In build-sequence and build-parallel, where a prebuilt wheel ends up depends on how the package is configured:

• Legacy pre_built: true: the wheel ends in wheels-repo/downloads.
• source: with pypi-prebuilt or hook-prebuilt: the wheel stays in wheels-repo/prebuilt.

Tools that collect wheels from wheels-repo/downloads after a build, for example to publish them, will silently miss these wheels once a package moves to source:. The build still succeeds. Bootstrap is not affected; it uses wheels-repo/prebuilt in both cases.

This blocks moving prebuilt packages to source: for anyone who publishes from wheels-repo/downloads.

Steps to reproduce

1. Create settings/six.yaml with one of:

   # legacy
   variants:
     cpu:
       pre_built: true

   # configured
   source:
     provider: pypi-prebuilt

2. Bootstrap, then rebuild from the build order with fresh output directories:

   echo "six==1.16.0" > requirements.txt
   fromager --settings-dir settings bootstrap -r requirements.txt
   cp work-dir/build-order.json .
   rm -rf wheels-repo sdists-repo work-dir
   fromager --settings-dir settings build-sequence build-order.json
   find wheels-repo -name '*.whl' -not -path '*/simple/*'

Legacy prints wheels-repo/downloads/six-1.16.0-py2.py3-none-any.whl; configured prints wheels-repo/prebuilt/six-1.16.0-py2.py3-none-any.whl. build-parallel with graph.json gives the same result.

This was raised in #1393 review and left as is to avoid changing legacy output. It is not tracked or documented as a migration difference.

Expected: moving a package from pre_built: true to a prebuilt provider should not change where its wheel ends up. If the new location is intended, document it as a migration step. Decide before 0.103.0 ships, since changing it after the release would break early adopters.

Found on new-resolver-config at 7cd77ac7. Related: #1393, #1395, #1414.