Add KiCad HTTP Library API v2 with volatile field support

[Sebbeben]

Summary

Adds KiCad HTTP Library API v2 support with volatile field support, split out from #1241 as discussed.

The v2 spec introduces volatile fields — fields that are shown in KiCad's UI but NOT saved to the schematic. This is ideal for dynamic data like stock quantity and storage location.

Changes

File	What changed
KiCadApiV2Controller.php	New controller at /kicad-api/v2/ with root, categories, category parts, and part detail endpoints
KiCadHelper.php	Added int $apiVersion parameter to getKiCADPart(), $volatile parameter to createField()
KiCadApiV2ControllerTest.php	Full test coverage: root endpoint, categories, parts, volatile fields, v1 vs v2 comparison, caching, auth

V2 API differences from V1

• Root endpoint returns links to categories (per v2 spec requirement)
• Stock field marked as volatile: True (shown in KiCad, not saved to schematic)
• Storage Location field marked as volatile: True
• All other fields remain non-volatile (saved to schematic as in v1)

V2 spec reference

• Draft: https://gitlab.com/RosyDev/kicad-dev-docs/-/blob/http-lib-v2/content/apis-and-binding/http-libraries/http-lib-v2-00.adoc
• V1 (current): https://dev-docs.kicad.org/en/apis-and-binding/http-libraries/index.html

Note

This PR is intentionally minimal — only the v2-specific additions. The underlying KiCad improvements (batch EDA editing, parameter export, populate command, etc.) were merged in #1241. This can be merged once the v2 spec is finalized, or kept as a draft until then.

[codecov]

Codecov Report

❌ Patch coverage is 94.87179% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 55.58%. Comparing base (78b1d41) to head (dc1754b).
⚠️ Report is 40 commits behind head on master.

Files with missing lines	Patch %	Lines
src/Controller/KiCadApiV2Controller.php	96.55%	1 Missing ⚠️
src/Services/EDA/KiCadHelper.php	90.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #1260      +/-   ##
============================================
+ Coverage     55.41%   55.58%   +0.16%     
- Complexity     8268     8281      +13     
============================================
  Files           610      612       +2     
  Lines         26519    26590      +71     
============================================
+ Hits          14696    14780      +84     
+ Misses        11823    11810      -13     

☔ View full report in Codecov by Sentry.
📢 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.

[jbtronics]

Are the new HTTP library things actual part of any KiCad release? I could not find anything about it for the upcoming KiCad 10.

In the linked documentation it seems that v2 was renamed to v1.1, and also includes other things than just a volatile property field (like timestamping)

[Sebbeben]

Sorry for the late reply! I got a bit ahead of myself with this one — I assumed that since the v2 spec documentation existed, it would ship with KiCad 10, but that doesn't appear to be the case.

You're right on both points. The spec was renamed from v2 to v1.1, and it's much more than just volatile fields. After going through the full spec, v1.1 is primarily about timestamp-based incremental caching — the update endpoint, restructured parts/categories responses with timestamps and pagination, field type declarations (essential/detail/hidden), shorthand keys, etc. The volatile fields part is actually commented out throughout the spec and explicitly marked as "not currently supported by KiCad."

This PR only addressed the volatile fields, which is ironically the one part that isn't even active in the spec. I'd suggest closing this for now and revisiting once v1.1 actually lands in a KiCad release — at which point a proper implementation covering the full spec (especially the caching/timestamping) would make much more sense.