Mocks: Add missing signalR property to mock server configuration response

[leekelleher]

Description

GetServerConfigurationResponse was updated in #22700 to require a signalR.skipNegotiation property, but the corresponding MSW mock handler in server.handlers.ts was not updated to match. This caused a tsc compilation error when running npm run compile in src/Umbraco.Web.UI.Client.

This PR adds the missing property to the mock response with a default value of false (matching the production default).

Testing

1. Check out this branch
2. From src/Umbraco.Web.UI.Client, run npm run compile
3. Confirm tsc completes without errors

[claude]

Claude finished @leekelleher's task in 51s —— View job

---

PR Review

Target: origin/v17/dev · Based on commit: 4ef96e15 · Classified as: Config-only (mock fixture sync)

Syncs the MSW mock handler for GET /server/configuration with the GetServerConfigurationResponse type, which gained a required signalR.skipNegotiation property in #22700. Without this, tsc fails because the mock object no longer satisfies the type.

---

No Critical, Important, or Suggestion findings. The value false correctly matches the production default for skipNegotiation.

---

Approved

This looks good to be merged as-is, but please do a manual sanity check and testing before merging.

[Copilot]

Pull request overview

This PR fixes the MSW mock for the server configuration endpoint in Umbraco.Web.UI.Client to align with the updated GetServerConfigurationResponse contract by adding the required signalR.skipNegotiation property (defaulting to false). This unblocks tsc compilation when using the mock handlers.

Changes:

• Added the missing signalR: { skipNegotiation: false } field to the mocked /server/configuration response.
• Ensured the mock response matches the generated ServerConfigurationResponseModel shape.

[AndyButland]

Thanks @leekelleher - I've confirmed this has resolved the problem. Will cherry-pick for release/17.5.0 and release/18.0 (once have established it's needed).

[AndyButland]

As discussed @leekelleher, cherry-picked to release/17.5.0 but still needs applying to the 18 release branch.

[leekelleher]

Thanks @AndyButland. It turns out that the v18 branches already had this fix.

I think it was during another cherry-picked merge-conflict: 8495405#diff-ed76282a1e7134cafd99e718981ede396c603af9aa5605758053d1764183fc9a