docs(nestjs): Document monitoring every @Cron method

includes/nestjs-sentry-cron-decorator.mdx

@@ -1,3 +1,29 @@
+### Monitor All `@Cron` Methods
+
+<AvailableSince version="11.11.0" />
+
+We recommend enabling `monitorCronJobs` on the Nest integration, which monitors every `@Cron` method without adding `@SentryCron` to each one:
+
+```typescript {filename:instrument.ts}
+import * as Sentry from "@sentry/nestjs";
+
+Sentry.init({
+  dsn: "___PUBLIC_DSN___",
+  integrations: [
+    Sentry.nestIntegration({
+      monitorCronJobs: true,
+      excludeCronJobs: ["cleanup-temp-files", /^Debug/], // Optional.
+    }),
+  ],
+});
+```
+
+The monitor slug is the `name` option of `@Cron`, or `ClassName.methodName` if there's no `name`. Set a `name` if your build minifies class names, so the slug doesn't change between deploys, or if the class and method names are long, since slugs are cut off at 50 characters. `excludeCronJobs` skips jobs whose slug matches a string exactly or a regular expression.
+
+Each check-in sends the schedule and time zone of `@Cron`, as described in [Monitor Config From `@Cron`](#monitor-config-from-cron). Jobs with schedules that can't be expressed in the Crons schedule format (for example, a job that runs every 10 seconds) aren't monitored. To monitor one, add `@SentryCron` and create the monitor in Sentry first. `@Cron` with a `Date` runs once and isn't monitored.
+
+### Monitor Specific Methods
+
 <AvailableSince version="8.16.0" />
 
 The NestJS SDK includes a `@SentryCron` decorator that can be used to augment the native NestJS `@Cron` decorator to send check-ins to Sentry before and after each cron job run.
@@ -29,8 +55,9 @@ export class MyCronService {
 }
 ```
 
+`monitorCronJobs` skips methods that have `@SentryCron`, so they check in once, with the slug and options you pass to `@SentryCron`.
 
-### Monitor Config From `@Cron`
+#### Monitor Config From `@Cron`
 
 <AvailableSince version="11.11.0" />
 
@@ -53,6 +80,6 @@ If `@Cron` has neither `timeZone` nor `utcOffset`, the job runs in your server's
 
 The monitor is created, and billed, on the first run. Each check-in overwrites the monitor's schedule and time zone with the ones from `@Cron`, so change them in your code rather than in Sentry.
 
-A six-field expression is sent without its seconds field if that field is a single number, such as `0 30 9 * * *`. Presets such as `@daily` and `@weekly` are sent too. Sub-minute schedules, `Date` values, `utcOffset`, month numbers with `@nestjs/schedule` 3 and earlier (use names such as `MAY`; steps such as `*/3` work), a `*/n` or full-range day field (such as `1-31` or `sun-sat`) combined with the other day field, and time zones that aren't IANA names send no monitor config, including any other options you pass. In those cases, pass a full monitor config to `@SentryCron` or create the monitor in Sentry first.
+A six-field expression is sent without its seconds field if that field is a single number, such as `0 30 9 * * *`. From the next SDK release after `11.12.0`, if the seconds field isn't `0`, a check-in margin of 2 minutes is sent too (or the `checkinMargin` you pass to `@SentryCron`, if it's larger), since the job checks in up to 59 seconds after the minute Sentry expects. This replaces a margin set in Sentry. Presets such as `@daily` and `@weekly` are sent too. Sub-minute schedules, `Date` values, `utcOffset`, month numbers with `@nestjs/schedule` 3 and earlier (use names such as `MAY`; steps such as `*/3` work), a `*/n` or full-range day field (such as `1-31` or `sun-sat`) combined with the other day field, and time zones that aren't IANA names send no monitor config, including any other options you pass. In those cases, pass a full monitor config to `@SentryCron` or create the monitor in Sentry first.
 
 To send check-ins without a monitor config, pass `{ fromCronDecorator: false }`.