fix(vaccinations): keep the booster mint inside the sections the grant opens

`POST /api/vaccinations/{id}/booster` is declared `("write", "profile")`, and
that is right for the act — filing the Impfpass and arming the booster it
suggests are one thing to the person doing them. The row it writes is not: a
`MeasurementReminder` belongs to the measurements section, every direct route
over the model declares it there, and creating one needs MANAGE. So a WRITE
grant scoped to the health background alone produced a reminder on the owner's
checkup list that the delegate could neither read nor change through the
section that owns it.

The seam is fenced the way the visits service fences a checkup closure, with
one difference stated at the call site: this refuses rather than skips. There
the closure is one effect of a larger save and reporting it as not done keeps
the save honest; here the reminder is the whole request, and a 201 over a row
that was never written would tell the person their booster is planned while
nothing rings. The prompt that raises the call asks the same question client-
side, so a delegate outside the section is not offered it in the first place;
the dose itself still logs either way.

`vaccination-booster-scoped-delegate.test.ts` drives the owner, a delegate
holding both sections, a profile-only delegate and a whole-record one. The
scoped-refusal leg fails against the previous handler, which answered 201 and
left the row.

src/app/api/vaccinations/[id]/booster/route.ts

@@ -13,11 +13,21 @@
  * even when a delegate is transcribing. The antigen is read from the dose's
  * catalogue entry server-side, never from the body — a client cannot key a
  * reminder onto an antigen the dose does not contain.
+ *
+ * The row it mints is a `MeasurementReminder`, and that model belongs to the
+ * `measurements` section: every direct route over it declares that domain, and
+ * creating one needs MANAGE there. So the act crosses a seam, and a grant
+ * scoped to the health background alone was never consent for the other side
+ * of it — it would produce a row on the owner's checkup list that the delegate
+ * can neither read nor change through the section that owns it. The seam is
+ * fenced the way the visits service fences a checkup closure: the mint runs
+ * only while the caller is inside `measurements`.
  */
 import { NextRequest } from "next/server";
 
 import { prisma } from "@/lib/db";
 import { apiHandler, requireRecordAuth } from "@/lib/api-handler";
+import { actingDomainVisibility } from "@/lib/sharing/acting-domains";
 import { annotate } from "@/lib/logging/context";
 import { auditLog } from "@/lib/auth/audit";
 import {
@@ -36,9 +46,24 @@ type RouteParams = { params: Promise<{ id: string }> };
 
 export const POST = apiHandler(
   async (request: NextRequest, { params }: RouteParams) => {
-    const { user } = await requireRecordAuth("write", "profile");
+    const { user, grantId } = await requireRecordAuth("write", "profile");
     const { id } = await params;
 
+    // Refused rather than skipped, and that is the difference from the visit's
+    // checkup closure: there the closure is one effect of a larger save and
+    // saying "not done" keeps the save honest, while here the reminder IS the
+    // request. Reporting success over a row that was never written would tell
+    // the person their booster is planned when nothing rings.
+    const visible = await actingDomainVisibility(prisma, grantId);
+    if (!visible("measurements")) {
+      annotate({ meta: { sharing_refusal: "booster_out_of_scope" } });
+      return apiError(
+        "Planning a booster needs access to this record's measurements",
+        403,
+        { errorCode: "vaccination.booster-out-of-scope" },
+      );
+    }
+
     const { data: rawBody, error: jsonError } = await safeJson(request, {
       maxBytes: 8 * 1024,
     });