fix: Monaco JSON schema validation not enforcing additionalProperties

[Copilot]

Monaco's JSON worker was silently ignoring the additionalProperties: false constraints defined throughout pr-filter-schema.ts, allowing arbitrary extra properties without any validation error.

Root causes

1. enableSchemaRequest not set → $ref resolution broken
Without enableSchemaRequest: false, Monaco's JSON worker attempted to fetch the schema from the uri field (https://pullrequest-manager.local/…). That address is unreachable, the fetch failed silently, and $ref resolution against the document root failed with it — meaning FilterNode, UserFilter, and ReviewerFilter definitions were never applied.

2. Custom-scheme fileMatch never matched
['pullrequest-manager:///profile-filter/*.json'] relied on Monaco's glob matcher treating the custom scheme as a literal prefix. It doesn't — the match failed and the schema was never associated with the editor model at all.

Fix

 monaco.languages.json.jsonDefaults.setDiagnosticsOptions({
   validate: true,
   allowComments: false,
+  enableSchemaRequest: false,
   schemas: [{
     uri: SCHEMA_URI,
-    fileMatch: [`${SCHEMA_PATH_PREFIX}*.json`],
+    fileMatch: ['**'],
     schema: PR_FILTER_SCHEMA,
   }],
 })

• enableSchemaRequest: false — forces Monaco to use the inline schema object directly, making $ref → #/definitions/* resolution work correctly.
• fileMatch: ['**'] — universally matches any model URI, bypassing the custom-scheme matching issue. Since the profile filter editor is the only Monaco JSON editor in this renderer, the broad match is safe.

The additionalProperties: false constraints in pr-filter-schema.ts were already correct and needed no changes.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud