feat: populate docs prose style guide as a landing page plus subpages - #26632

Replace the scaffold with the populated prose style guide,
structured as a README.md landing page plus one subpage per topic so
GitHub auto-renders the landing when readers open the style-guide
folder:

- style-guide/README.md (landing): intro, section list, conventions
  for editing Coder docs (semantic line breaks with an
  incremental-adoption touch-paragraph rule, no navigational
  "see"), Vale enforcement summary, relationship to the public
  contributing page, third-party references including the Google
  developer documentation style guide.
- style-guide/audience-and-scope.md: every page targets one audience
  working toward one outcome; the install-vs-deploy Coder example;
  pick one audience per page; pick one outcome per page; declare
  audience and scope up front; canonical Coder personas (Dave, Ada,
  Perry, Steven as primary; Melissa, Tommy, Caitlin, Felipe, Sergio,
  Tara as secondary) with each persona's role, what they need from
  the docs, and the Coder surface they typically work with.
- style-guide/voice-and-tone.md: address the reader directly, avoid
  first-person singular, reserve first-person plural for Coder
  Technologies the company (with a contact-sales example, an
  explicit ban on "we" for the product itself, and a ban on
  combined "you and the docs"), active voice, present tense with a
  conditional/predictive "will" exception, no sentence-ending
  prepositions.
- style-guide/word-choice.md: Coder product and feature names (with
  the Coder CLI always in backticks rule), brand names (with a
  parallel rule for the Terraform CLI in backticks), Dev Container
  terminology (proper-noun specification vs lowercase instance),
  phrasal verbs and their noun forms generalized as a table (set
  up/setup, log in/login, sign in/sign-in, log out/logout, back
  up/backup, roll out/rollout, start up/startup, shut down/shutdown,
  with the Quickstart exception), refer to versus see, learn more
  versus next steps with an ableism rationale, tutorial versus
  walkthrough with an ableism rationale, select versus click, don't
  assume simplicity or difficulty (covers both "simple"/"easy" and
  "complex"/"non-trivial"), avoid weasel words (vague attributions
  in the Wikipedia sense), plain language for product actions with
  an industry-term exception scope for the Linux kill command, the
  SIGKILL signal, and the disabled config flag state.
- style-guide/accessibility-and-inclusion.md: WCAG 2.1 AA minimum and
  AAA stretch target; heading structure (one H1 per page, no skipped
  levels, content between headings); inclusive pronouns;
  inclusive-language substitutions including a dedicated row for
  sanity check alternatives; descriptive link text; alt text and
  decorative-image conventions; plain English for international
  readers (no idioms, no Latin abbreviations); page descriptions in
  docs/manifest.json; reading level with WCAG 2.1 AAA SC 3.1.5
  mapping; color contrast deferred to the docs site theme.
- style-guide/capitalization-and-punctuation.md: sentence-case
  headings, no gerund-leading headings with documented exceptions
  (Pricing, Billing, Logging, etc.), trailing heading punctuation in
  three tiers (periods and exclamation marks forbidden at error
  severity, question marks allowed sparingly at suggestion
  severity, characters inside backticks exempt for both), no em or
  en-dashes with corrected example showing parenthetical em-dash use
  rather than series-joining, Oxford comma, US-style quotation,
  semicolons sparingly, rare exclamation marks, numeric ranges.
- style-guide/formatting.md: text formatting (bold for UI with
  greater-than separator for navigation paths, italics for emphasis,
  code font for identifiers as a bulleted list) and block elements
  (code blocks with language fences and Prism reference, callouts
  with tightened scenarios, tabs with the div class="tabs" syntax
  and macOS/Linux/Windows example, lists with a five-item prose-list
  cap and explicit terminal-punctuation rule, tables with a
  narrow-table guideline that reconsiders the structure when many
  columns are needed, links including non-docs codebase relative
  paths, images, screenshots sparingly with a maintenance-burden
  rationale and the Lorna Jane example-vs-screenshot adaptation),
  with cross-references to accessibility-and-inclusion.md for link
  text and alt text.
- style-guide/numbers-units-and-dates.md: digits everywhere
  preference, non-breaking space between number and unit with
  pre-render and post-render demonstrations and a window-shrink tip,
  Month Day, Year date format, 12-hour time with AM/PM, ordinals
  exception.
- style-guide/editor-setup.md: placeholder.

Update repo references to the new path (AGENTS.md and its symlinks,
.claude/docs/DOCS_STYLE_GUIDE.md, docs/about/contributing/documentation.md,
docs/.style/README.md, docs/.style/styles/Coder/README.md, and a
comment in .github/workflows/ci.yaml). Reformat the touched
paragraphs in each of those files to semantic line breaks per the
new touch-paragraph rule.

The guide dogfoods its own rules. Source lines follow semantic line
breaks (sembr.org), and the same convention applies corpus-wide
through an incremental touch-paragraph rule: when a contributor
edits any line inside a paragraph, the whole paragraph is
reformatted in semantic line breaks as part of the same edit.
Navigational "see" is replaced with refer to, check out, or visit
throughout the guide. Em-dashes inside demo examples are HTML
entities so the source stays ASCII while still rendering the
character. Body prose prefers two sentences over a semicolon. Latin
abbreviations are replaced with plain English.

- word-choice: simplify dev container terminology to match the spec's own usage. Reserve capitalized 'Dev Container' for the proper-noun shorthand 'Dev Container Spec'. Use lowercase 'dev container' for the category. Note that Coder's product 'Dev Containers' integration is named by the product feature rule.
- accessibility-and-inclusion: add a collapsible details block on the rationale for avoiding Latin abbreviations. Drop the implication that WCAG 2.1 bans them. Cite Google, Microsoft, 18F, and PLAIN style guidance instead.
- audience-and-scope: replace 'workspace user' with 'end user'. Add a hub pages and category landing pages section that allows broad titles when the page's job is to route. Rewrite 'Declare audience and scope up front' to drop the metadata line pattern and add a prerequisite callout subsection for privileged pages. Reorder primary personas with Perry first. Add Elliot the End User as a stopgap umbrella persona for non-developer end users. Replace he/she pronouns with they throughout.

…ules

Two follow-ups from the round-2 review feedback that bpmct and Nick
both wanted codified rather than left implicit:

- accessibility-and-inclusion: new 'Page title and sidebar title'
  section that defines the H1 and the manifest.json sidebar title as
  separate labels with different jobs. The H1 is grammatical and
  outcome-focused. The sidebar title is a navigation label that fits
  the sidebar and reads fast under breadcrumb context. The two must
  each stand alone but do not need to be identical. Worked example
  uses the Administration > Authentication > Google path.

- formatting: new 'Semantic line breaks' section that documents the
  sembr convention the rest of the style guide already follows.
  Records the convention so writers and reviewers don't have to
  reverse-engineer it from the existing prose.

…ghlighter note

Add a Word choice rule that keeps internal-only references (issue-tracker
IDs, private repositories, internal-only links) out of published docs, so
every reader and contributor can open every linked resource. List it in the
README section table.

Correct the Formatting code-block guidance: the docs site highlights with
Speed-Highlight (content-based detection), not Prism. The fence label still
drives GitHub and editor highlighting and is required by markdownlint MD040.
Add `powershell` for Windows blocks, clarify `console` versus `sh`, and note
`tf` covers Terraform and HCL.

Part of DOCS-434.

Filed via Coder Agents on Nick's behalf.

…, and preposition rules

Address review feedback from the Quickstart Part 2 experiment (#26712):

- formatting.md: a command with no output uses `sh`, not `console`;
  `console` requires shown output with `$` prefixes; `sh` is the canonical
  shell label over `bash`/`shell`; document the generated CLI-reference
  exception. Add a "Learn more / See also" list example (link fragments,
  no terminal periods, no leading "Or", clean lead-in stem).
- capitalization-and-punctuation.md: new Commas section covering the
  introductory-element comma, no comma in a short compound predicate, the
  Oxford comma, and a note that semantic line breaks never change
  punctuation.
- word-choice.md: prefer "learn" or "find out" over "see" for comprehension
  outcomes.
- audience-and-scope.md: give the audience only what it needs; do not add
  wrong-role caveats when the audience already has the access.
- voice-and-tone.md: reframe trailing prepositions as a judgment call with
  examples in both directions.

Refs: DOCS-434
Filed via Coder Agents on Nick's behalf.

…n abbreviation rule

Two policy revisions to the in-progress prose style guide.

Line breaks: replaces the semantic line breaks (sembr) rule with a hard one-sentence-per-line rule, on the rationale that one sentence per line is easier to produce reliably for humans and LLMs alike, avoids the short-line-in-quick-succession clutter that sembr generates, and still wins on diff clarity. A small edit changes one line, so reviewers see the changed sentence in isolation.

- formatting.md: the 'Semantic line breaks' rule is replaced with 'One sentence per line'. The new rule section is itself written in the new format so it dogfoods the rule. The two 'Don't' examples now flag clause-level breaks (the old sembr convention) and fixed column wrapping as the two failure modes.

- README.md: the 'Conventions for editing Coder docs' section now points at one sentence per line. The 'Incremental adoption' subsection retains the touch-paragraph rule, rephrased as 'reformat to one sentence per line', and acknowledges that earlier paragraphs in this style guide still carry sembr from prior commits in this PR.

- capitalization-and-punctuation.md: the 'Semantic line breaks do not change punctuation' subsection is deleted. The footgun it guarded against (using a line break in place of a comma) cannot happen when every sentence sits on one line, so the section has no analog under the new rule.

Latin abbreviations: backs out the ban on all Latin abbreviations and allows five specific ones: 'e.g.', 'i.e.', 'etc.', 'vs.', and 'et al.' (citation contexts). These five are near-universal in industry technical writing.

- accessibility-and-inclusion.md: 'Avoid Latin and other foreign-language abbreviations' becomes 'Latin abbreviations' (permissive heading for a permissive rule). The new section codifies four practical rules: prefer parentheses around 'e.g.' and 'i.e.' clauses to avoid comma cascades; one period when 'etc.' ends a sentence, both periods when 'etc.' ends a parenthetical that ends a sentence; the author-date citation form for 'et al.'; less common Latin ('a priori', 'q.v.', 'viz.', 'n.b.', 'cf.', 'ibid.') stays banned. The 'Why' details block now justifies the carve-out rather than the ban, citing the same Google, Microsoft, 18F, and PLAIN sources reframed for the permissive policy.

- The planned 'Coder.LatinAbbreviations' Vale rule is dropped from the documentation. The Idioms section above gets its own '*Documentation-only. Planned Vale rule Coder.Idioms.*' footer so the planned-rule reference is preserved when the joint footer goes away.

The rest of the style guide still carries sembr from prior commits on this PR. The touch-paragraph rule in 'README.md' handles incremental conversion as paragraphs are edited.