fix: validate devtoolsOptionsUri in extensionEnabledState handler

[adilburaksen]

Summary

handleExtensionEnabledState() in _devtools_extensions.dart reads devtoolsOptionsUri directly from query parameters and passes it without validation to DevToolsOptions.setExtensionEnabledState(), which creates the target file and any missing parent directories.

// Before fix — no URI validation
final devtoolsOptionsFileUri = Uri.parse(devtoolsOptionsFileUriString);
// → passes directly to File.fromUri(devtoolsOptionsFileUri) in extension_enablement.dart

An untrusted caller that can reach the DevTools server (e.g., another local process, or a browser tab via cross-origin requests) can create or overwrite any file writable by the server process:

GET /api/extensionEnabledState?
    devtoolsOptionsUri=file:///home/user/.ssh/authorized_keys
    &extensionName=pwned&enabled=true

The resulting file content is a valid YAML map:

extensions:
  pwned: enabled

Fix

Reject requests where devtoolsOptionsUri:

• does not use the file: scheme, or
• does not end with devtools_options.yaml

Both conditions are required for a legitimate DevTools options file. Any other value is rejected with HTTP 400.

Impact

Without the fix, any local process or browser tab able to reach the DevTools HTTP server can create or overwrite arbitrary files on the developer's machine with attacker-controlled YAML content.

[gemini-code-assist]

Code Review

This pull request adds validation for the devtoolsOptionsUri query parameter to ensure it is a local file URI pointing to a devtools_options.yaml file, mitigating potential file overwrite vulnerabilities. Feedback was provided to tighten the path validation logic, as the current implementation could match unintended filenames.