info providers: optionally fetch a part's data when its page is first viewed (to reduce cost/api calls)

[samyk]

Looking up every part of a large inventory at an info provider up front is slow, and for paid providers such as Canopy expensive, while most of those parts are never looked at again. This adds an opt-in mode where a part's data is fetched the first time somebody opens its info page, and only once.

How it behaves:

• The page renders as usual and then asks the server for the data itself, so opening it is not slowed down. It shows "Fetching product data from …", reloads with the new data once it is there, or says that the daily limit is reached or the lookup failed.
• Only parts without an info provider reference are considered. Only missing data is filled in (manufacturer, MPN, notes, pictures, parameters, mass, manufacturing status, a price if the part has none); nothing existing is changed, since nobody reviews the result. The part then gets the provider reference, which marks it as done and lets the normal info provider tools update it later.
• A failed lookup is remembered for a day, so a dead product is not requested on every view. A short-lived lock keeps two viewers of the same part from both triggering a request, and the session is released during the fetch so the user's other pages are not blocked.

How a part is matched to a provider (the check done on every page view never contacts a provider):

1. An order detail's supplier product URL that the provider recognises (URLHandlerInfoProviderInterface). Canopy is not a URL handler, so its ASIN extraction for the configured marketplace is handled as a special case.
2. An order detail whose supplier name equals the provider's name (ignoring case, spaces and punctuation) and that has a supplier part number: the provider is searched for that number, and a result is accepted only if its provider ID, MPN or order number equals it (ignoring case, leading zeros, a leading #, and a vendor prefix set apart by a separator or equal to the start of the provider's name). No exact result is a failed lookup; it never guesses. Several exact results are accepted only if they all carry the same MPN.

Settings:

• Info provider general settings: "Fetch data when a part is viewed" (a multi-select of the active providers; PROVIDER_FETCH_ON_VIEW=key1,key2) and "Max. lookups per day when viewing parts" (PROVIDER_FETCH_ON_VIEW_DAILY_LIMIT, default 100, 0 = unlimited; per provider, counting parts looked up). Empty by default, which is the stock behaviour.
• Canopy keeps its own "Fetch data when a part is viewed" switch and daily limit in its provider settings.

Implementation: ProviderOnViewMatcher (which providers are enabled, matching, exact-result selection), ProviderOnViewFetcher (lock, daily cap, failure memo, filling missing data), a CSRF-protected POST /{id}/fetch_on_view route that requires read permission on the part (the administrator opts in with the setting, and only missing data is added), a small Stimulus controller and template for the notice, translations and a docs section. 37 unit tests cover the matching.

The branch has two commits: the first adds the mode for Canopy only, the second generalises it to any provider.

Notes for review:

• Exercised end to end with Canopy, and with four store providers that are in separate PRs (info provider for pololu.com #1577, info provider for adafruit.com #1578, info provider for sparkfun.com #1579, info provider for the bambu lab store #1580); this PR does not depend on them at code level and works with any provider through its key and the existing interfaces.
• The fetcher itself has no unit test (PartInfoRetriever is final); it was exercised against real parts only.
• While a provider refuses requests, each part viewed in that time is remembered as failed for a day and counts against the daily limit.
• Being allowed to view a part is enough to trigger a fetch. If you would rather require edit permission, that is a one-line change.

[codecov]

Codecov Report

❌ Patch coverage is 45.83333% with 156 lines in your changes missing coverage. Please review.
✅ Project coverage is 64.13%. Comparing base (a7f2d49) to head (bf8de1a).

Files with missing lines	Patch %	Lines
...vices/InfoProviderSystem/ProviderOnViewFetcher.php	3.33%	145 Missing ⚠️
src/Controller/PartController.php	15.38%	11 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1581      +/-   ##
============================================
- Coverage     64.46%   64.13%   -0.33%     
- Complexity    10210    10342     +132     
============================================
  Files           762      766       +4     
  Lines         32711    32999     +288     
============================================
+ Hits          21087    21164      +77     
- Misses        11624    11835     +211     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.