Fix uv index: move indexes to uv.toml, keep sources in pyproject.toml

[lowvoltage]

All uv invocations use --no-config --config-file=uv.toml, which causes [tool.uv] configuration in pyproject.toml to be silently ignored for resolution purposes. Commit c7359e4 placed both [[tool.uv.index]] and [tool.uv.sources] in pyproject.toml, but indexes there are not used by uv during resolution, causing packages from private indexes to not be found.

The fix splits configuration correctly between the two files:

• [[index]] entries go in uv.toml (via ResolveConfig.uv_config()) where uv actually reads them for package resolution
• [tool.uv.sources] stays in pyproject.toml since uv rejects [sources] in uv.toml
• Indexes referenced by sources are also declared in pyproject.toml so uv can validate the name references

[benjyw]

This yields a warning

Found both a `uv.toml` file and a `[tool.uv]` section in an adjacent `pyproject.toml`. The following fields from `[tool.uv]` will be ignored in favor of the `uv.toml` file:
- index

This is OK in practice since we know that the index entries in both are identical, and we only put them in pyproject.toml so that validation of sources works, but it's a bit of a smell. Let me think on this some more.

[benjyw]

OK, looks like with --no-config --config-file=uv.toml we don't get that warning because pyproject.toml is completely ignored for config purposes. But the tool.uv.indexes table is still consulted for the purpose of validating the tool.uv.sources in dependencies, so in that one specific case tool.uv is consulted, but it doesn't count as "config" for the purpose of --no-config --config-file=... 😓

It seems that [tool.uv.foo] in pyproject.toml was at one point intended to be completely equivalent to [foo] uv.toml, but then some awkward corner cases crept in.

[benjyw]

But weirdly I can't actually reproduce this. In manual testing directly with uv it seems happy to read the indexes from pyproject.toml even with --no-config --config-file=uv.toml (and this was the case when I originally tested #23443, but I've just verified again).