fix: allow system resource servers other than the My Account API to be updated

[erdtsieck]

🔧 Changes

updateResourceServer() decides whether to send the restricted payload with this guard:

if (update.is_system === true || update.name === 'Auth0 My Account API') {

Neither half holds up:

• is_system is listed in stripUpdateFields, and stripFields() runs on the payload in
  DefaultHandler.processChanges() before updateResourceServer() is called. update.is_system
  is therefore always undefined and that branch is dead code.
• The fallback matches one hardcoded name, so the Auth0 My Account API is the only system resource
  server that works. Every other one — the Auth0 My Organization API (https://{domain}/my-org/) in
  our case — takes the full-update path, which includes name, and the Management API rejects it
  with Payload validation error: 'Additional properties not allowed: name'.

Since calculateChanges() puts every matched asset into update whether or not anything changed,
this makes import fail on every run after the first, and it aborts the whole processChanges stage
for resourceServers.

This reads is_system off the existing resource server instead, which is where it actually survives —
getType() keeps is_system in its allowlist when it sanitizes system resource servers, and it runs
before processChanges(). The hardcoded name comparison then has nothing left to do and is removed:
the My Account API is covered by is_system like any other system resource server.

No change in behaviour for the My Account API or for non-system resource servers.

📚 References

Fixes #1484

🔬 Testing

Added should update a system resource server other than "Auth0 My Account API" without name, which
mirrors the existing My Account API test with the My Organization API. On master it fails with
expected 'Auth0 My Organization API' to equal undefined, which is exactly the name that the
Management API rejects; with this change it passes.

The existing system resource server tests (sanitizing in getType, authorization_policy in the
update payload, should update "Auth0 My Account API" without name and is_system) all still pass, so
the removed name comparison is not load-bearing.

Verified end-to-end against a real tenant as well, with AUTH0_INCLUDED_ONLY: ["resourceServers"] and
a config directory holding both system APIs. On 8.44.0 the first import creates both and the second
one fails on the My Organization API; with this change both runs are clean.

📝 Checklist

• All new/changed/fixed functionality is covered by tests (or N/A)
• I have added documentation for all new/changed functionality (or N/A) — N/A, bug fix with no
  public API or config surface change

[erdtsieck]

A note on the red E2E tests as Node module check, since it is not caused by this change:

• The four failures are all Problem updating clients {"name":"Deploy CLI", ...} with Nock: No match for request on PATCH /api/v2/clients/Vp0gMRF8.... Nothing in them touches resource servers — the recordings only contain a GET /api/v2/resource-servers, no update, so updateResourceServer() is never reached in that suite.
• Running AUTH0_HTTP_RECORDINGS=lockdown npm run test:e2e:node-module locally on this branch and on an unmodified master gives byte-for-byte the same failures, including the same four.
• The job appears to fail on every fork PR (fix: prevent client grant loss and duplication in directory format exports #1473, Guard undefined handler.identifiers in keywordPreservation.ts #1463, fix: apply AUTH0_INCLUDED_CONNECTIONS on export #1442) and pass on every PR pushed to an auth0-owned branch, which is what you would expect if the job needs a CircleCI context that fork builds do not receive.

Unit tests with Node LTS, Unit tests with Node current, TypeScript, lint and format are all green, and those cover the added regression test.

Happy to rebase or adjust anything if you would rather see this shaped differently.