Issue #3586573: Replace hardcoded /admin/ paths with route-based URL generation

Closes #3586573.

Replaces three hardcoded /admin/... path strings with route-based URL generation so Monitoring works correctly on sites using Rename Admin Paths (or any module that rewrites admin paths at the routing layer).

Changes

• src/Controller/SensorList.php: the Edit dropdown link's destination query param was hardcoded to the literal string admin/reports/monitoring. Replaced with Url::fromRoute('monitoring.sensor_list')->toString(). Added the Drupal\Core\Url import.
• src/Plugin/monitoring/SensorPlugin/WatchdogAggregatorSensorPlugin.php: Url::fromUserInput('/admin/reports/dblog/event/' . $wid) → Url::fromRoute('dblog.event', ['event_id' => $wid]). The dblog.event route is guaranteed by this plugin's provider: 'dblog' attribute, so no guard is needed.
• src/Plugin/monitoring/SensorPlugin/ImageMissingStyleSensorPlugin.php: Url::fromUserInput('/admin/content/files/usage/' . $fid) → Url::fromRoute('view.files.page_2', ['arg_0' => $fid]). Wrapped in a RouteProvider::getRouteByName() / RouteNotFoundException guard so the sensor degrades to a plain count (no link) if the shipped files view or its usage page display has been removed or renamed by the site builder.

Backwards compatibility

No functional change on sites without Rename Admin Paths — the generated URLs resolve to the same paths as before. No config or schema changes.

Manual test

With Rename Admin Paths installed and admin renamed to e.g. adm:

1. Edit any sensor from the sensors overview, save — redirect now lands on /adm/reports/monitoring instead of /admin/reports/monitoring.
2. Configure a watchdog_aggregator sensor with verbose output; trigger any watchdog row; the linked wid resolves to /adm/reports/dblog/event/{id}.
3. Configure the image_style_missing sensor; the "N places" link resolves to /adm/content/files/usage/{fid}. Remove or rename the page_2 display on the files view and confirm the sensor still renders (as plain text) without throwing.

Note on view.files.page_2

That's the default display id of the core-shipped files view's usage page. Since admins can rename/delete the display, the code guards against the missing-route case. If a maintainer prefers a sturdier lookup, an alternative would be to iterate \Drupal::entityTypeManager()->getStorage('view')->load('files')'s displays and match by path — happy to revise if preferred.