Add open-ended bc-version range shorthand [N..]

A closed range like [23..28] wrongly implies guidance stops applying after
BC28, so a reviewer targeting BC29+ would not match the file. Introduce an
open-ended shorthand [N..] meaning ''version N and every later version''.

- validate_frontmatter.py: RANGE_SHORTHAND allows an optional upper bound;
  expand_bc_version returns the normalized string ''N..'' for open-ended.
- read.md: document the fourth bc-version form and its matching rule
  (matches target >= N; not enumerable).
- write.md: prefer [N..] over a closed range for a feature introduced in N
  and not expected to be removed.
- Apply [23..] to the actionable-errors article (actionable errors shipped
  in BC23 and are not version-bounded above).
- README: mention [N..] in the frontmatter example.

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

README.md

@@ -72,7 +72,7 @@ Every knowledge file is a markdown file with mandatory YAML frontmatter. Files t
 
 ```yaml
 ---
-bc-version: [all]                       # or [26..28] for version-gated guidance
+bc-version: [all]                       # or [26..28], or [26..] for "26 and later"
 domain: performance                     # security | performance | ux | telemetry | ...
 keywords: [query, filtering, partial]   # free-text tags for retrieval
 technologies: [al]                      # al | javascript | powershell | ...