fix(onboarding): leave a trail for the three settings columns the flow writes

The setup flow writes a record's module map, its glucose unit and its unit
preference. All three have a dedicated settings route that records an audit
row, and the flow recorded none, so "why did my modules change" had no answer
in the activity panel. Restarting the flow did write a row, which made the gap
look like an oversight rather than a decision, because it was one.

Same event names as the dedicated routes, since it is the same column and the
panel should group them. The module row names the keys that actually moved and
the domains kept for their content.

tests/integration/onboarding-needs.test.ts

@@ -229,6 +229,17 @@ describe("PATCH /api/onboarding/answers", () => {
       select: { glucoseUnit: true, unitPreference: true },
     });
     expect(row).toEqual({ glucoseUnit: "mmol/L", unitPreference: "imperial" });
+
+    // Same trail as the two dedicated settings routes, so it does not matter
+    // which surface the person changed the units from.
+    const actions = (
+      await getPrismaClient().auditLog.findMany({
+        where: { userId: user.id },
+        select: { action: true },
+      })
+    ).map((entry) => entry.action);
+    expect(actions).toContain("user.glucose-unit.update");
+    expect(actions).toContain("user.unit-preference.update");
   });
 
   it("does not re-ask the units the account already holds", async () => {
@@ -304,6 +315,15 @@ describe("POST /api/onboarding/complete", () => {
     expect(statusOf(state, "confirm")).toBe("done");
     expect(state.completedAt).not.toBeNull();
 
+    // The activity panel has to be able to answer "why did my modules change".
+    const audit = await getPrismaClient().auditLog.findMany({
+      where: { userId: user.id, action: "user.modules.update" },
+    });
+    expect(audit).toHaveLength(1);
+    expect(
+      (audit[0].details as { changed?: string[] } | null)?.changed,
+    ).toContain("medications");
+
     // Somebody changes their mind in Settings, then the confirm screen is
     // replayed. The second call must leave that decision alone: the latch is
     // what stops a questionnaire from re-applying itself over a later choice.