Task URLs Interact Poorly With Casing Redirect Rules

## Summary

The admin plugin sends multiple AJAX requests on every page load in the format of, `/admin/task:` (e.g., `/admin/task:getNotifications`). Additionally, a common practice (at least in the Windows/IIS world) is to enforce lowercase URL paths by redirecting requests with uppercase characters to equivalent all-lowercase URLs, leaving filenames and query strings unchanged.

Some examples:

- `https://example.com/About` -> `https://example.com/about`
- `https://example.com/about/Team.jpg` -> no change
- `https://example.com/About/Team.jpg` -> `https://example.com/about/Team.jpg`
- `https://example.com/search?term=Grav` -> no change

The current URL structure of the admin plugin AJAX requests is such that it triggers a redirect when a web server is configured in the above way. For example, `/admin/task:getNotifications` gets redirected to `/admin/task:getnotifications`. When the lowercased URL is requested, Grav returns an error message, causing a "Fetch failed" box to appear on every single page in the admin web interface.

## Steps to Reproduce

1. Using URL Rewrite in IIS, or Mod Rewrite in Apache, configure a rule that will redirect visitors to a lowercased version of a URL with uppercase characters. See below for example configuration. Place this rule before the rewrite rules for the index page.
2. Open up the Dashboard page in the admin web interface.

Example IIS rewrite rule:
```xml

```

Example Apache rewrite rule:
```
RewriteCond %{REQUEST_URI} ^([^.]*?[A-Z][^.]*?)(\/[^/]+\.[^/]+)?$
RewriteRule .* ${tolower:%1}%2 [R=301,L]
```

## Expected Result

The Dashboard loads without displaying any error messages, and notifications are displayed.

## Actual Result

A "Fetch failed" error message appears on the page, and the notifications pane gets stuck in a loading animation.

## Possible Resolutions

1. Remove web server configuration that redirects requests to enforce lowercasing. This resolution does not align with how I would like my site to function, in that it will trigger 404 error pages for pages with uppercase characters in the URL instead of taking visitors to where they want to go (recognizing that most visitors do not anticipate a difference between an `/About` or `/about` URL, for example).
2. Leave the burden to me (and others like me) to add web server configuration that specifically knows about the `task:` URLs and does not trigger a redirect for them. This seems like a brittle solution, as these URLs could change in the future, or more could be added. Along the same lines, the `/admin` part of the path is simply the default, and is something that Grav offers configuration for. By adding additional rewrite rules in the webserver configuration, it creates two places where that path name is configured instead of one, leading to a potential "gotcha" should there ever be a want or need to change this path in the future.
3. Update the Grav Admin plugin to supply the method name via query string. E.g., `/task:getNotifications` becomes `/task?m=getNotifications` or something similar. It appears as if the colon character is currently acting like a custom implementation of a query string, so let's simply switch it to use the standard mechanism instead of rolling our own.
4. Update the Grav Admin plugin to be case-insensitive for method names.
5. Update the Grav Admin plugin to only use lowercase characters in its URLs. This potentially triggers the same issue, but in reverse (however, I think it is extraordinarily uncommon for a website to enforce any uppercase characters rather than lowercase).
6. Update the main Grav project to include an option to redirect visitors to enforce lowercase URLs. This would remove the need for configuration at the web server level, and would allow Grav/Grav Admin to manage its own exceptions to the rewrite rule (moving the burden of the brittleness described in option 2 to the admin plugin itself, where it can be managed more effectively).

Start by reviewing the Grav Admin plugin's `/admin/task:` AJAX entry point and reproduce the Dashboard failure with a server-side lowercase redirect. Compare the possible URL, method-casing, and rewrite-rule approaches, then verify that notifications load without a Fetch failed message under the affected configurations.

Written by the indexing model from the issue text.