1287: url for scratch assets

[DNR500]

Relates to issue: 1287

Resolves

Part of #1287 — load Scratch library thumbnails (sprites, costumes, sounds, backdrops) from a configurable host (RPF editor-api) instead of the MIT CDN.

Depends on the 13.7.3 sync PR (sync-13.7.3-experience-cs). This PR should target that branch until it merges.

Follow-up work in other repos:

• editor-ui will pin @RaspberryPiFoundation/scratch-gui and pass libraryAssetHost / libraryAssetsFetchWithHeaders
• editor-api will serve assets from /api/scratch/assets/internalapi/asset/...

Reviewer note

This PR is functionally fairly focused, but is stacked on top of the larger 13.7.3 sync PR.

Main review focus:

• embedder API shape
• asset URL generation
• authenticated thumbnail loading
• error handling
• context refactor

What this PR does

Adds configurable library asset loading so embedders (like Code Classroom) can load library thumbnails from their own asset host instead of the MIT CDN.

GUI / embedder API

Adds two new <GUI /> props:

• libraryAssetHost
• libraryAssetsFetchWithHeaders

These are wired through LibraryAssetConfigProvider.

Using context removes prop drilling across the library UI while keeping the public <GUI /> API unchanged. I originally tried this with prop drilling (which looks like a norm in this codebase) but it touch a lot of components. As these values shouldn't change often context should be suitable here.

libraryAssetHost

Changes where library thumbnails are loaded from.

libraryAssetsFetchWithHeaders

Routes thumbnail loading through ScratchImage / scratch-storage so requests can include auth + project metadata headers.

When libraryAssetsFetchWithHeaders is enabled:

• Thumbnails load through ScratchImage
• Requests can include auth + project metadata headers

Why

Scratch library metadata already lives inside scratch-gui, but the actual asset binaries were still loading from the MIT CDN.

For RPF, those assets need to come from editor-api, including authenticated requests when required.

This PR keeps the default MIT behaviour unchanged:

• no custom host → MIT CDN

But allows editor-ui to redirect library asset loading to:
{apiUrl}/api/scratch/assets

without forking the library metadata.

I also based this on the Scratch 13.7.3 release tag rather than develop so we avoid unintentionally pulling unreleased upstream changes into RPF builds.

Why libraryAssetsFetchWithHeaders is separate

Library thumbnails can currently load in two ways:

1. Direct image URLs (<img src="...">)

   • Works well for public assets like the MIT CDN

2. ScratchImage + scratch-storage

   • Allows auth headers and project metadata to be attached
   • Required for protected editor-api assets

libraryAssetHost only changes the asset URL.

libraryAssetsFetchWithHeaders explicitly opts into the authenticated ScratchImage path and allows headers to be sent which html images wouldn't.

Longer term, this logic could potentially move entirely into ScratchImage, making the extra flag unnecessary. See the TODO that is currently in library-item.jsx

---

ScratchImage error handling

While testing with editor-ui + editor-api, failed asset requests caused noisy errors and poor behaviour in the library UI.

This PR makes those failures degrade more gracefully:

• fallback UI instead of broken tiles
• reduced console noise
• library remains usable even when assets are missing or auth is not configured

---

Testing

New / updated tests

• test/unit/lib/library-asset-url.test.js
• test/unit/contexts/library-asset-config-context.test.jsx