Move .lsp.json in the idfkit bump as well as .mcp.json

[samuelduchesne]

Summary

bump-idfkit.yml now moves .lsp.json to the newest idfkit-lsp release on the new idfkit level, in the same pull request as .mcp.json. The header comment, which said that idfkit-lsp has never been published to PyPI, is corrected.

Motivation

1. idfkit-lsp has been on PyPI since 0.2.0, and The language server path resolves nothing: idfkit-lsp is not on PyPI #17 is closed. The workflow comment and the pull request body still described the earlier situation.
2. The plugin's EnergyPlus delivery-pins step checks both pins. During the 26.2.0 adoption the bump moved only .mcp.json, and the step waited until Deliver idfkit-lsp 0.3.0 (idfkit 1.1.1) #27 moved .lsp.json by hand.

Change

1. Lookup. The "Find the server releases on this level" step resolves idfkit-lsp with the same pypi_released_on used for idfkit-mcp, unless check-order reported that idfkit-lsp has no release on the level.
2. Pin. A new step substitutes "idfkit-lsp==X.Y.Z" in .lsp.json, using the same text substitution as .mcp.json. It requires exactly one match.
3. Pull request. .lsp.json is in add-paths. The body states either the new LSP pin or that .lsp.json is unchanged.
4. Unchanged behaviour:
   • idfkit-mcp remains a hard stop;
   • a missing idfkit-lsp release does not stop the run.

Verification

1. Against PyPI, using tools/adoption.py at governance-2026.18:
   • pypi_released_on returns 0.3.0 for idfkit-lsp on idfkit 1.1.1;
   • it returns 0.11.1 for idfkit-mcp on 1.1.1;
   • it returns None for an unreleased level.
2. The substitution matches the current .lsp.json once.
3. The workflow parses as YAML. It has not been run end to end. The first real run will be the next dispatch from idfkit's notify-downstream.yml.