Remove em dashes across branch per new house style rule

Pure copy-editing pass, no functional/behavioural change. Replaces
every em dash (—) in docs/puzzle-page.md and the Puzzle Page source
comments touched by this branch with a comma, a new sentence, or a
plain hyphen, whichever reads most naturally, per a new permanent
house-style rule against using em dashes anywhere.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

Author: andresilva-guardian

ab-testing/config/abTests.ts

@@ -158,7 +158,7 @@ const ABTests: ABTest[] = [
 		shouldForceMetricsCollection: false,
 	},
 	/**
-	 * Puzzles & Games rollout — tier v0 (the master switch).
+	 * Puzzles & Games rollout, tier v0 (the master switch).
 	 *
 	 * Gates the baseline Puzzles & Games experience: the new Puzzles Hub
 	 * page, and the 6 V0 puzzle pages (sudoku easy/medium/hard/killer,
@@ -167,7 +167,7 @@ const ABTests: ABTest[] = [
 	 * from puzzles" rail, and the hub's sub-nav has no links yet.
 	 *
 	 * This is the master switch for the whole Puzzles & Games experience:
-	 * turning it off (or down to 0%) hides everything — the hub, the V0
+	 * turning it off (or down to 0%) hides everything: the hub, the V0
 	 * puzzle pages, and (by the cumulative design below) every later tier
 	 * too, since v1/v2 only take effect when this is also enabled.
 	 *
@@ -190,10 +190,10 @@ const ABTests: ABTest[] = [
 		shouldForceMetricsCollection: false,
 	},
 	/**
-	 * Puzzles & Games rollout — tier v1 (w/c 12 Oct launch).
+	 * Puzzles & Games rollout, tier v1 (w/c 12 Oct launch).
 	 *
 	 * Only takes effect when `puzzles-new-hub` (v0) is ALSO enabled for the
-	 * reader — this test does nothing on its own, by design, so the
+	 * reader. This test does nothing on its own, by design, so the
 	 * rollout can never end up in an inconsistent state (e.g. v1 features
 	 * showing while the v0 baseline they build on is switched off).
 	 *
@@ -224,11 +224,11 @@ const ABTests: ABTest[] = [
 		shouldForceMetricsCollection: false,
 	},
 	/**
-	 * Puzzles & Games rollout — tier v2 (future, no launch date confirmed
+	 * Puzzles & Games rollout, tier v2 (future, no launch date confirmed
 	 * yet as of this writing).
 	 *
 	 * Only takes effect when BOTH `puzzles-new-hub` (v0) AND
-	 * `puzzles-new-hub-v1` are ALSO enabled for the reader — same
+	 * `puzzles-new-hub-v1` are ALSO enabled for the reader, same
 	 * cumulative-by-design principle as v1 above, applied one tier further.
 	 *
 	 * On top of v0+v1, this tier activates: the On the Ball and Film Reveal

dotcom-rendering/docs/puzzle-page.md

@@ -28,7 +28,7 @@ const sampleMoreFromPuzzlesAndGames: PuzzleItem[] = [
 /**
  * Illustrative canonical URL matching `frontend`'s public URL shape for
  * puzzle pages (top-level, mirroring crosswords, distinct from the
- * `/puzzles-and-games` hub) — purely a fixture value, not something DCR
+ * `/puzzles-and-games` hub), purely a fixture value, not something DCR
  * validates or enforces the shape of.
  */
 const canonicalUrlForSlug = (slug: string): string => {

dotcom-rendering/fixtures/manual/puzzlePage.ts

@@ -34,11 +34,11 @@ import type { FEPuzzlePageType } from '../types/puzzlePage';
  * blocks (Masthead, Section, Footer, AdSlot, ShareButton.island) rather than
  * duplicating them.
  *
- * Puzzle Page is scoped to iframe-based puzzles only — crosswords remain on
+ * Puzzle Page is scoped to iframe-based puzzles only, crosswords remain on
  * their existing, separate `/crosswords/*` flow
  * (`ArticleDesign.Crossword` / `src/layouts/CrosswordLayout.tsx`), which is
  * unrelated to this layout. There is accordingly no setter byline, PDF
- * link, or comments rendering here — none of the current `PuzzleConfig`
+ * link, or comments rendering here, none of the current `PuzzleConfig`
  * registry entries have any equivalent concept.
  */
 
@@ -53,7 +53,7 @@ const puzzleGroupLabels: Record<PuzzleConfig['puzzleGroup'], string> = {
  * no equivalent concept, so a minimal, fixed format value is used to satisfy
  * its prop contract without fabricating article-specific data (tags,
  * branding, etc.). This is read-only reuse of existing exported enum
- * values — it does not modify `articleFormat.ts` or any crossword decision
+ * values, it does not modify `articleFormat.ts` or any crossword decision
  * logic.
  */
 const puzzlePageFormat = {

dotcom-rendering/src/layouts/PuzzlePageLayout.tsx

@@ -2,7 +2,7 @@
  * DCR's single source of truth for the structural/rendering behaviour of
  * each supported Puzzle Page slug.
  *
- * Puzzle Page is scoped to iframe-based puzzles only — crosswords remain on
+ * Puzzle Page is scoped to iframe-based puzzles only, crosswords remain on
  * their existing, separate `/crosswords/*` flow
  * (`ArticleDesign.Crossword` / `src/layouts/CrosswordLayout.tsx`), which is
  * unrelated to this registry and is not unified into Puzzle Page. See

dotcom-rendering/src/model/puzzles/puzzleConfigs.ts

@@ -18,7 +18,7 @@ import {
  * `editions`) exported from `validate.ts` rather than duplicating them.
  *
  * Note: unlike some other DCR page types, there was no pre-existing
- * `validate.<pageType>.ts` file to mirror here — every other page type's
+ * `validate.<pageType>.ts` file to mirror here, every other page type's
  * validator (including the unrelated Puzzles Hub's `validateAsPuzzlesPageType`)
  * still lives in the shared `validate.ts`, only their *tests* are split
  * into per-page-type files (e.g. `validate.puzzlesPage.test.ts`). This file

dotcom-rendering/src/model/validate.puzzlePage.ts

@@ -9,7 +9,7 @@ import type { PuzzleItem } from './puzzlesPage';
  * (currently just the title, plus optional related-content links) resolved
  * by frontend for a given puzzle `slug`.
  *
- * Puzzle Page is scoped to iframe-based puzzles only — there is no
+ * Puzzle Page is scoped to iframe-based puzzles only, there is no
  * component-rendered case (crosswords remain on their existing, separate
  * `/crosswords/*` flow), so this type carries no crossword-specific fields.
  */
@@ -20,7 +20,7 @@ export interface PuzzlePageInstance {
 	 * (e.g. `"2026-09-11"`). This is prep work for a future V1
 	 * calendar-navigation feature (the reader will be able to navigate from
 	 * a calendar to a specific past puzzle, so the page won't always show
-	 * "today's" puzzle) — DCR currently accepts and validates this field
+	 * "today's" puzzle). DCR currently accepts and validates this field
 	 * but does **not** yet wire it into any rendering logic or the iframe
 	 * URL. See "Open questions" in `docs/puzzle-page.md`.
 	 *