style(web): bold the "Secrets:" prefix in the settings-modal footers

Weights the label so the band reads as a labelled fact rather than one
run of prose — the eye lands on what the line is about before reading
which store it names.

Rendered as a `span` inside the existing `Text` rather than as a sibling
in the `Group`: `Text` renders a `<p>`, so a nested one would be a `<p>`
inside a `<p>` (invalid, and the browser closes the outer paragraph
early), and a sibling would take the Group's `gap` and sit too far from
the value it labels. `inherit` keeps it at the label's own size.

Splitting the text is why the assertions move off `getByText`: it matches
a string against an element's *direct* text nodes, so "Secrets: OS
keychain" now reads as two fragments even though it renders as one line.
The unit tests, both modal tests, and the four stories assert
`toHaveTextContent` on the band instead, which reads the full subtree.

Verified in the running dev server: prefix 700, store name 500, both at
the same 12px.

Signed-off-by: cliffhall <cliff@futurescale.com>

clients/web/src/components/groups/ServerSettingsModal/ServerSettingsModal.test.tsx

@@ -920,9 +920,11 @@ describe("ServerSettingsModal", () => {
           }}
         />,
       );
-      expect(
-        screen.getByText("Secrets: Memory (this session only)"),
-      ).toBeInTheDocument();
+      // Full-text assertion: the "Secrets:" prefix is its own `<span>`, which
+      // `getByText`'s direct-text-node matching would not see as one string.
+      expect(screen.getByTestId("secret-storage-footer")).toHaveTextContent(
+        "Secrets: Memory (this session only)",
+      );
     });
 
     it("renders no footer when the backend didn't report a store", () => {