Fetch the WordPress.org API to determine Theme/Plugin names.

[dd32]

Motivation for the change, related issues

See #1487

Before	After
Screen.Recording.2025-09-02.at.1.27.48.pm.mov	Screen.Recording.2025-09-02.at.1.27.27.pm.mov

Implementation details

A APIBasedFetchResource class is inserted between the Core{Plugin,Theme}Resource and FetchResource to allow the API to be fetched as an intermediate step.
The name property is added to the Core{Plugin,Theme}Reference to prevent the name being sourced from the ZIP.
The name property is passed through to other steps where possible.

This is not perfect, but it works and provides a basis for some other incremental improvements.

Testing Instructions (or ideally a Blueprint)

https://playground.wordpress.net/?plugin=woocommerce
http://127.0.0.1:5400/website-server/?plugin=woocommerce

[adamziel]

My only note – I wouldn't break the entire Blueprint execution just because we can't fetch the name. Otherwise this PR seems like a great addition – thank you @dd32!

[adamziel]

Aha, this isn't just a name now. The api.wordpress.org call also provides the download_link. Will it ever be different from https://downloads.wordpress.org/theme|plugin/${zipName}?

[dd32]

I thought about this after the fact.. Specifically because of closed plugins..

I was thinking of updating it to the previous as the fallback as well as the latest-stable for the ZIP.

The ZIP is unlikely to change location, but I figured since I had the data here, I might as well use it to avoid the 301 from latest-stable to the versioned link.

If dependencies are requested as in #2582 then the API failing to retrieve would be more of a show-stopper, but even then, just failing to install the dependencies is probably a better thing than playground halting.

[adamziel]

@JanJakes would you be able to shepherd this PR? I think it might be good to go but I'd still love to get your opinion.

[JanJakes]

👍 I'll check it out.