feat(media-use): derive provider cost tier from the registry

[miguel-heygen]

What

A new providerTierFor(name) export derives a provider's cost tier (local / network_free / network_paid) from the registry's existing A / N / P declarations, and the resolve event carries the derived value as provider_tier alongside the provider it came from.

Why

The registry already decides whether a provider is local, free over the network, or paid over the network. That decision is what tells a caller whether resolving through a given provider can spend the user's credit. Nothing downstream could read it, so anything needing that distinction had to infer it by string-matching provider names, which gives one fact two owners and breaks quietly whenever a provider is renamed or added.

How

buildProviderTierIndex() folds the registry into a name-to-tier map and is exported so its conflict rule is testable against a fixture; providerTierFor() reads the map built from the real registry.

A name declared under two media types must carry the same tier in both. heygen.audio.sounds serves both bgm and sfx, and heygen.asset.search serves both image and icon. If a name could be free under one type and paid under another, whether a resolve cost credit would depend on which type happened to serve the request, so the index throws at import rather than silently picking one.

The property is sparse, matching auth_method: absent when the record carries no provider (cache and reuse hits) or the name is not declared. No provider, cascade, or resolve behavior changes. This is one added property on an event that already fires.

Test plan

• Unit tests added/updated
• Manual testing performed
• Documentation updated (if applicable)

node skills/media-use/scripts/lib/registry.test.mjs passes 20/20, including five new cases: tier per declaration, cross-media-type agreement for every declared provider, undefined for undeclared and nullish names, a fixture with one name at two tiers throwing, and the same name repeated at one tier being accepted.

node skills/media-use/scripts/resolve.test.mjs reports 45 passed / 1 failed; the same suite on an untouched main checkout reports 42 passed / 1 failed, so the three added tests are the only difference and the one failure (smart grade merges measured adjust) is pre-existing and unrelated.

Those three are end-to-end rather than unit: each spawns the real resolve CLI as its own process, lets telemetry.mjs build the request, and reads the tier off the payload a local HTTP server actually receives, one case per tier (network_paid, network_free, local). The pre-existing seam test, which covers an undeclared provider getting no tier, now shares the same harness.

Two paths a local suite cannot reach were exercised by hand against the real service:

• A genuine HeyGen TTS resolve using real OAuth credentials, with telemetry redirected to a local server so nothing reached production. The event carried provider_tier: network_paid and auth_method: oauth together, which is the combination no automated case can produce without credentials.
• One real resolve with no redirection, to confirm the property survives ingestion rather than only serialization. It arrived carrying its tier, with the auth method absent, confirming the two properties stay independent for a non-heygen provider.

bunx oxlint and bunx oxfmt are clean on all changed files. Repository CI reports every check as skipped for this branch, since the workflows are path-filtered and this PR touches only skills/**.