docs: fix Vale prose errors in dev docs

Move commas/periods inside quotation marks (Google.Quotes) in the ACES
preflight notes, and replace spaced em-dashes with colons/semicolons/commas
(Google.EmDash) in the CTF organizer guide and CTF technical docs.

Clears the 'Docs prose (changed Markdown)' gate that failed on PR #1365
(dev -> aws-dev).

Author: Brad-Edwards

docs/architecture/aces-catalog-package-boundary-preflight-1232.md

@@ -1,7 +1,7 @@
 # ACES Catalog And Scenario Package Boundary Preflight
 
 Issue: GitHub #1232, "03 - ACES migration: design legacy-safe catalog and
-scenario package boundary".
+scenario package boundary."
 
 Status: pre-implementation guidance.
 

docs/architecture/aces-catalog-readonly-presentation-preflight-1254.md

@@ -1,7 +1,7 @@
 # ACES Catalog Read-Only Presentation Preflight
 
 Issue: GitHub #1254, "13 - ACES migration: expose read-only ACES catalog
-fields in CMS API and scenario editor".
+fields in CMS API and scenario editor."
 
 Status: pre-implementation architecture guidance. This note does not implement
 API endpoints, template changes, serializers, editor actions, ACES authoring,

docs/architecture/aces-operation-api-projections-preflight-1275.md

@@ -1,7 +1,7 @@
 # ACES Operation API Projections Preflight
 
 Issue: GitHub #1275, "16 - ACES migration: expose read-only operation
-status and snapshot APIs".
+status and snapshot APIs."
 
 Status: pre-implementation architecture guidance. This note does not implement
 API routes, serializers, services, models, migrations, UI, or cleanup jobs, and
@@ -106,7 +106,7 @@ persistence/projection design:
   `shared.schemas.aces_operation` for record kind, contract kind/version,
   contract profile, digest, payload size, diagnostic key allowlists, and
   secret-pattern rejection. API code must still apply a response allowlist
-  because "safe to persist internally" is not the same as "safe to return".
+  because "safe to persist internally" is not the same as "safe to return."
 - Response redaction: responses exclude secrets, credential values, private
   keys, bearer tokens, token-bearing or presigned URLs, prompt bodies,
   generated scripts, command strings, terminal output, raw package bodies, CTF
@@ -115,7 +115,7 @@ persistence/projection design:
 - Error envelopes: canonical `/api/v1` errors use `shared.api.errors`.
   Legacy Mission Control compatibility, if touched, uses existing
   `MissionControlAPIView` legacy handling. Raw ACES/provider exceptions are
-  sanitized into fixed messages such as "Operation status unavailable".
+  sanitized into fixed messages such as "Operation status unavailable."
 - Observability: logs use `safe_log_value` for external-ish ids and include
   counts/statuses only. No payload dumps in application logs, request logs,
   test failure snapshots, OpenAPI examples, or audit records.

docs/architecture/aces-operation-sidecar-persistence-preflight-1273.md

@@ -1,7 +1,7 @@
 # ACES Operation Sidecar Persistence Preflight
 
 Issue: GitHub #1273, "14 - ACES migration: implement operation
-receipt/status/snapshot persistence sidecar".
+receipt/status/snapshot persistence sidecar."
 
 Status: pre-implementation architecture guidance. This note does not implement
 models, migrations, APIs, event handlers, jobs, or UI projections, and it is

docs/architecture/aces-operation-status-range-event-preflight-1274.md

@@ -1,7 +1,7 @@
 # ACES Operation Status Range Event Projection Preflight
 
 Issue: GitHub #1274, "15 - ACES migration: project operation status through
-range event handling".
+range event handling."
 
 Status: pre-implementation architecture guidance. This note does not implement
 models, migrations, adapters, event handlers, workers, APIs, or UI behavior.

docs/architecture/aces-operation-status-snapshot-projection-preflight-1234.md

@@ -1,7 +1,7 @@
 # ACES Operation Persistence And Range Projection Preflight
 
 Issue: GitHub #1234, "05 - ACES migration: design operation, status,
-snapshot, and range projection persistence".
+snapshot, and range projection persistence."
 
 Status: pre-implementation architecture guidance. This note does not implement
 models, migrations, APIs, event handlers, or UI projections.

docs/architecture/gcp-range-cell-backend-preflight-1341.md

@@ -1,6 +1,6 @@
 # GCP Range-Cell Backend Preflight
 
-Issue: GitHub #1341, "Implement GCP range-cell provisioning backend".
+Issue: GitHub #1341, "Implement GCP range-cell provisioning backend."
 
 This is requirement-free pre-implementation guidance. The GitHub issue title,
 body, and acceptance criteria are the shipping contract. This note is not an

shifter/shifter_platform/documentation/docs/features/ctf-organizer-guide.md

@@ -40,12 +40,12 @@ the plaintext flag is never persisted after creation.
 
 Additional controls:
 
-- **Release time** — schedule a challenge to appear partway through the event.
-- **Prerequisite** — lock a challenge until another is solved.
-- **Visibility** — hide a challenge from the participant list until you release it.
-- **Target instance / port** — point participants at the right host in their range.
-- **Files** — upload challenge attachments.
-- **Hints** — optional, point-reducing hints.
+- **Release time**: schedule a challenge to appear partway through the event.
+- **Prerequisite**: lock a challenge until another is solved.
+- **Visibility**: hide a challenge from the participant list until you release it.
+- **Target instance / port**: point participants at the right host in their range.
+- **Files**: upload challenge attachments.
+- **Hints**: optional, point-reducing hints.
 
 A challenge can carry multiple flags (for multi-stage solves), each validated
 independently.
@@ -114,6 +114,6 @@ hour offsets you configure.
 
 ## See Also
 
-- [CTF](ctf) — the participant experience.
-- [CTF technical documentation](../technical/shifter_platform/ctf) — models, services,
+- [CTF](ctf): the participant experience.
+- [CTF technical documentation](../technical/shifter_platform/ctf): models, services,
   scheduling, and range provisioning.

shifter/shifter_platform/documentation/docs/technical/shifter_platform/ctf.md

@@ -2,7 +2,7 @@
 
 Capture-the-flag is a Django app (`ctf`) layered on the platform's range system. It
 owns event/challenge/scoring data and orchestrates a dedicated range per participant
-by calling the existing CMS range services — it does not introduce a second
+by calling the existing CMS range services; it does not introduce a second
 provisioning path.
 
 ## Responsibility
@@ -53,24 +53,24 @@ challenge creation, and submission checking compares against the hash.
 Business logic lives under `ctf.services` (views stay thin):
 
 - `event`, `challenge`, `flag`, `bracket`, `hint`, `award`, `attachment`,
-  `email_template`, `notification` — entity operations.
-- `participant/` — `lifecycle`, `bulk_import`, `queries`.
-- `scoring/` — materialized-leaderboard hot path with an authoritative recompute
+  `email_template`, `notification`: entity operations.
+- `participant/`: `lifecycle`, `bulk_import`, `queries`.
+- `scoring/`: materialized-leaderboard hot path with an authoritative recompute
   fallback (`get_scoreboard`, `calculate_score`, ranks, stats, timeline, and the
   `recompute_*` maintenance helpers).
-- `authorization`, `audit` — access checks and audit trail.
+- `authorization`, `audit`: access checks and audit trail.
 
 ### Range Provisioning
 
 `ctf.services.range` provisions a range per participant from `event.scenario_id` via
-CMS range services — the same path Mission Control uses to launch a range.
+CMS range services, the same path Mission Control uses to launch a range.
 
-- `provision.py` — `provision_participant_range(participant_id)` runs under a
+- `provision.py`: `provision_participant_range(participant_id)` runs under a
   per-participant row lock so concurrent manual and scheduled provisioning cannot
   double-assign a range, with an exponential-backoff retry wrapper.
-- `batch.py` — throttled event-wide provisioning, pacing participant spin-ups.
-- `lifecycle.py`, `status.py`, `tasks.py` — teardown, status reads, and task wiring.
-- `recovery.py` — `recover_participant_range(participant_id, *, strategy,
+- `batch.py`: throttled event-wide provisioning, pacing participant spin-ups.
+- `lifecycle.py`, `status.py`, `tasks.py`: teardown, status reads, and task wiring.
+- `recovery.py`: `recover_participant_range(participant_id, *, strategy,
   operator, spare_range_instance_id=None)` recovers a destroyed participant range
   (organizer-only). `rebuild` provisions a fresh range via the CMS bridge; `reassign_spare`
   consumes an available `CTFSpareRange` from the participant's own event pool and
@@ -79,10 +79,10 @@ CMS range services — the same path Mission Control uses to launch a range.
   `cms.services.reassign_range_owner`). The intent is persisted as a `CTFRangeRecovery`
   row keyed on participant + old range + strategy; resumption after a partial failure is
   data-driven (recorded replacement id and the live old-range status), so retries never
-  duplicate the replacement or the audit row. The old range is always destroyed — there
+  duplicate the replacement or the audit row. The old range is always destroyed; there
   is no disposition/forensics-retention choice. Recovery writes one `risk_register` audit
   row.
-- `spares.py` — `provision_event_spares(event_id, target_count, *, operator=None)` tops up
+- `spares.py`: `provision_event_spares(event_id, target_count, *, operator=None)` tops up
   an event's prewarmed spare-range pool (`CTFEvent.spare_range_count`), each spare owned by
   a dedicated, auto-created managed system user (never a `CTFParticipant`) until consumed.
   `get_event_spare_summary(event_id)` reports pool counts for the admin surface;
@@ -97,9 +97,9 @@ does not go stale and provisioning stays responsive to shutdown.
 
 Two management commands operate the event runtime:
 
-- `run_ctf_scheduler` — long-running scheduler that drives batch range provisioning,
+- `run_ctf_scheduler`: long-running scheduler that drives batch range provisioning,
   cleanup, reminders, and scheduled tasks, writing a liveness heartbeat.
-- `ctf_recompute_leaderboard` — recomputes materialized leaderboard columns
+- `ctf_recompute_leaderboard`: recomputes materialized leaderboard columns
   authoritatively when reconciliation is needed.
 
 ## Boundaries
@@ -112,5 +112,5 @@ Two management commands operate the event runtime:
 
 ## See Also
 
-- [CTF](../../features/ctf) — participant guide.
-- [CTF Organizer Guide](../../features/ctf-organizer-guide) — running an event.
+- [CTF](../../features/ctf): participant guide.
+- [CTF Organizer Guide](../../features/ctf-organizer-guide): running an event.