feat: configureLottie for the engine's global settings, and the renderer settings the engine reads

[Gamote]

What

Some lottie-web settings belong to a loaded copy of the engine rather than to one animation, so they can never be props: the prefix of the element IDs it mints (read at every mint) and how finely it draws curves (read whenever it builds one). v2 exposed them by re-exporting the engine's player; v3 removed that with no replacement.

configureLottie({ idPrefix, quality }), exported from the barrel, sets both for all three engine builds. It takes effect at once on every engine that has loaded an animation, and again right before every load, which also puts the settings back should anything else on the page have changed them. Set it once, at startup.

• IDs are prefixed by default: the base lottie-react plus each build's own name (-lottie, -lottie_svg, -lottie_light). Today Lottie and LottieLight on one page are two engine copies whose counters both start at one and share every ID (the fault Unique identifier conflict in monorepo with multiple Lottie animations #117 describes); with the suffixes they cannot. Two copies of the library each set a base of their own. IDs change from __lottie_element_N to lottie-react-lottie__lottie_element_N for everyone; the migration guide says so.
• quality passes through to setQuality (low / medium / high / a number; the engine's own default is 150 and any number above 1 restores it).
• Each build declares its engine and name as one pair next to its hook (fullEngine, svgEngine, lightEngine); the components import the pair, so a mispairing cannot compile. useLottieAnimation(engine, options) takes the pair.
• TS Definitions for SVG rendererSettings missing from type AnimationConfig #89: the per-renderer rendererSettings types are a superset of lottie-web's declarations, adding what the engine reads and lottie-web omits: runExpressions on every renderer, id and contentVisibility on svg and canvas, width/height on svg (as attribute values, so strings too), filterSize on html.
• Docs: a "Configuring the engine" page, a configureLottie reference page, the migration guide's LottiePlayer line, the rendererSettings reference row.

Nothing runs against an engine at module scope: importing any pair still costs only that pair. Budgets after: Lottie 4.79 of 4.9 kB, useLottie 3.76 of 3.85, the svg and light pairs 4.82 of 4.9; the load path now has about 100 bytes of headroom, worth knowing for the next change there.

Verified

• Tests: the settings module (default suffixes, apply-at-once to loaded engines and at each later load, quality only once set, merge); the real engine (animationID carries lottie-react-lottie__… and lottie-react-lottie_light__… by default, a configured base on the next load, setQuality reached at once and again before every load); the type table (the widened fields typecheck where read and are refused elsewhere). pnpm check green: 488 tests, coverage 100 / 97.46 / 100 / 100, 36 pages rendered.
• Real browser, the packed build in a Next.js 16 Turbopack app: Lottie and LottieLight side by side share zero IDs where the previous build shared all four; a page calling configureLottie({ idPrefix: "crm", quality: "low" }) mints crm-lottie__… and crm-lottie_light__….

Closes the code half of #38, #117 and #89; their replies follow the release.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 99.92%. Comparing base (9e67c64) to head (6e3201f).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #137   +/-   ##
=======================================
  Coverage   99.91%   99.92%           
=======================================
  Files          47       48    +1     
  Lines        1232     1253   +21     
  Branches      362      365    +3     
=======================================
+ Hits         1231     1252   +21     
  Misses          1        1           

☔ 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.