Fix dead docs.checklyhq.com links and stale sample output in guides

developer-fixtures.mdx linked to docs.checklyhq.com/cli/* URLs with
mangled slugs (overviewproject-structure, overviewconstructs-reference)
that 404; replace with relative links to /constructs/overview,
/constructs/project, /constructs/retry-strategy, and
/guides/getting-started-with-monitoring-as-code so mint broken-links
guards them. create-multiple-monitors.mdx showed a deploy-preview line
inconsistent with its own code sample (index 3 host is www.checklyhq.com,
so the logical ID is multi-url-monitor-3checklyhq.com).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: sbezludny

guides/create-multiple-monitors.mdx

@@ -116,7 +116,7 @@ Create:
     UrlMonitor: multi-url-monitor-0checklyhq.com
     UrlMonitor: multi-url-monitor-1checklyhq.com
     UrlMonitor: multi-url-monitor-2checklyhq.com
-    UrlMonitor: multi-url-monitor-3developers.checklyhq.com
+    UrlMonitor: multi-url-monitor-3checklyhq.com
     UrlMonitor: multi-url-monitor-4checklyhq.com
 ```
 

guides/developer-fixtures.mdx

@@ -47,9 +47,9 @@ For small teams just getting started with Checkly, this is all you need to do to
 
 It's a great feature of Checkly that any check can have totally custom settings for every aspect of its running: it can run at a custom cadence, from its own geography, with its own logic for retries. This means that if, for example, you're creating a new test specifically to check localization settings, you can set just that check to run from dozens of geographies, even if most checks only need three or four.
 
-Of course, we don't want to give our fresh developer over a dozen settings that she needs to set just to create her first check. New Checks created either in the web UI or from your code environment via the CLI will default to using the [global configuration](https://docs.checklyhq.com/cli/overviewproject-structure/#global-configuration). You can view and edit this global config in `checkly.config.ts`, you can see a reference on this configuration and options under the `project` [construct documentation](https://docs.checklyhq.com/cli/overviewconstructs-reference/#project). Some suggestions for default configuration:
+Of course, we don't want to give our fresh developer over a dozen settings that she needs to set just to create her first check. New Checks created either in the web UI or from your code environment via the CLI will default to using the [global configuration](/constructs/overview#global-configuration). You can view and edit this global config in `checkly.config.ts`, you can see a reference on this configuration and options under the `project` [construct documentation](/constructs/project). Some suggestions for default configuration:
 
-* Set a generous `RetryStrategy`! Some failures can look extremely worrying even if they happen once, but it's worth double-checking that the problem wasn't entirely ephemeral. Full [documentation of retry configuration is on our docs site](https://docs.checklyhq.com/cli/overviewconstructs-reference/#retrystrategy).
+* Set a generous `RetryStrategy`! Some failures can look extremely worrying even if they happen once, but it's worth double-checking that the problem wasn't entirely ephemeral. Full [documentation of retry configuration is on our docs site](/constructs/retry-strategy).
 
 * If you're encouraging microservice developers or frontend engineers to add checks, consider setting the default frequency to be relatively low. It's great to test edge cases or unusual scenarios, but someone without exposure to Operations is unlikely to need to run a check every minute.
 
@@ -83,7 +83,7 @@ Some important things to remember when working with a group of checks:
 
 So group settings will override global settings, and individual settings will override everything else.
 
-* While groups are a useful feature of Checkly, and will make sense for some applications, you may also be served by using Javascript and Typescript's native features for [inheritance](https://www.typescriptlang.org/docs/handbook/2/classes.html). Since files can inherit modules from others, it's possible to share configuration very cleanly, is as complex a heirarchy as you'd like, using these native features. This especially may make sense if you're going deep into [Monitoring as Code](https://docs.checklyhq.com/guides/getting-started-with-monitoring-as-code/) and want to set up a complex repository for all monitoring. Native features also help support the next section on using fixtures to share code blocks.
+* While groups are a useful feature of Checkly, and will make sense for some applications, you may also be served by using Javascript and Typescript's native features for [inheritance](https://www.typescriptlang.org/docs/handbook/2/classes.html). Since files can inherit modules from others, it's possible to share configuration very cleanly, is as complex a heirarchy as you'd like, using these native features. This especially may make sense if you're going deep into [Monitoring as Code](/guides/getting-started-with-monitoring-as-code) and want to set up a complex repository for all monitoring. Native features also help support the next section on using fixtures to share code blocks.
 
 ## Sharing code for repeated tasks
 While there are sophisticated ways to share authentication across checks discussed in other guides, it's good to know how to share code with fixtures for common repeated tasks. Let's imagine an example where we've got a web shop with a login modal that we need to fill out before doing further account actions. The goal of my check isn't really to test this modal, it just needs to be filled out before my *real* testing, where I look at my demo user's recent orders.