MAINT: Post-v1.0.1 release follow-ups for main

[romanlutz]

Description

Post-release follow-ups for main after the v1.0.1 patch release, plus one pre-existing build bug found while running the release process. Two independent commits.

1. Point the docs site at v1.0.1 (.github/docs-versions.yml)

Step 10 of doc/contributing/10_release_process.md. Bumps default: and stable: from 1.0.0 to 1.0.1 so the site root and the /stable/ alias serve the latest release, and updates the versions: list to point at releases/v1.0.1.

Judgment call worth a reviewer's eye: I replaced the 1.0.0 entry rather than listing both. The file already lists 0.12.1 but not 0.12.0, so superseded patch versions do not appear to be kept in the picker. That precedent is suggestive but not conclusive — the file was seeded with 0.12.1 already present, so it never demonstrably went through an add-then-replace cycle. If we'd rather keep both 1.0.0 and 1.0.1 in the picker, re-adding the entry is a 3-line change.

Note the version bump to 1.1.0.dev0 (the other half of step 10) is already on main, and uv.lock / frontend/package-lock.json agree with it, so nothing was needed there. The only reference to "the latest release" anywhere in the codebase was this file; other 1.0.0 matches are unrelated (harm-category taxonomy version, ARM template contentVersion, dependency floors, historical prose, test fixtures) and were left alone.

2. Fix a Unicode crash in build_scripts/prepare_package.py

Pre-existing bug on main that breaks Windows release builds whenever stdout is not a true Win32 console — piped, redirected, or captured by CI.

On Windows, Python encodes sys.stdout with the legacy ANSI code page (cp1252) when stdout is not a console. The script prints non-ASCII status glyphs (✓, ❌, ✅) that cp1252 cannot represent, so the print raises UnicodeEncodeError.

This is not cosmetic. Observed during the v1.0.1 release: the script crashed on print("✓ Dependencies installed") immediately after npm install had succeeded. The exception propagated out of build_frontend() and killed main(), so the copy step never ran and pyrit/backend/frontend/ was never populated — a decorative character turned a working build into a hard failure. The two failure-path prints are worse still: a genuine frontend build error would have been masked by an unrelated encoding traceback.

Fix is to make stdout robust rather than strip the glyphs — a small _configure_utf8_stdio() helper called at the top of main() reconfigures stdout/stderr to UTF-8 with errors="replace", guarded for streams that are None (pythonw) or lack reconfigure(). This fixes all six affected prints at once and keeps future non-ASCII output safe. Self-contained, +21 lines, no behavior change beyond encoding.

Tests and Documentation

No new tests — this is release metadata plus a build-script fix, neither of which is covered by the test suite. No test suite run was warranted since no library code changed. JupyText not run: no docs .py/.ipynb files touched.

Validation performed:

• docs-versions.yml parsed with build_scripts/resolve_docs_matrix.py, the same script .github/workflows/docs.yml uses to derive the build matrix → default=1.0.1, stable=1.0.1, matrix [latest, 1.0.1, 0.14.0, 0.13.0, 0.12.1]. Its load_config also validates that default/stable are among the version slugs, so a mismatch would have failed the check.
• Unicode fix, reproduce-then-resolve on Windows with stdout piped and PYTHONUTF8/PYTHONIOENCODING both unset:
  • Baseline: sys.stdout.encoding is cp1252; printing \u2713 raises UnicodeEncodeError: 'charmap' codec can't encode character '\u2713'.
  • After the fix: encoding flips cp1252 → utf-8 and all six affected messages emit cleanly.
  • Guard paths exercised directly — sys.stdout = None and a StringIO without reconfigure both no-op safely.
  • A/B through real code: prepare_package.main() piped returns 0 and prints the ✓/✅ messages; the same run with the new helper stubbed to a no-op reproduces the original UnicodeEncodeError. Same code, fix on/off, crash on/off.
• Full end-to-end, uv run python build_scripts/prepare_package.py 2>&1 | Select-Object -Last 18, piped: completes green with EXIT=0 through ✓ Dependencies installed → ✓ Frontend built successfully → ✅ Package preparation complete!. A separate run where npm install genuinely failed printed ❌ Failed to build frontend and returned 1 with no encoding traceback — i.e. the previously-masked failure path now surfaces the real error.
• ruff format, ruff check, and ty all pass; full pre-commit ran clean on both commits.