Re-vendor the merge gate and convert the docs to reference links

AGENTS.md

@@ -215,7 +215,7 @@ The repo runs a review loop on every PR: local agent iteration plus remote autom
 **Do not merge - and do not enable auto-merge - unless ALL of these hold:**
 
 1. Required status checks are green (`mergeStateStatus: CLEAN`), **and**
-2. A Copilot review is confirmed on the **current head SHA** (not an earlier push), **and**
+2. A Copilot review is confirmed on the **current head SHA** by matching the review's commit SHA to the head, not an earlier push - a push makes required checks go green **before** the re-review lands, so a green merge-state can precede the current-head review and never signals readiness on its own, **and**
 3. **Every** Copilot finding on that head SHA is closed out - all review threads resolved, **and** any issue-level Copilot comments (which have no resolve action) triaged and replied to - so zero outstanding findings remain, **and**
 4. The maintainer has given **explicit** permission to merge.
 

CODESTYLE.md

@@ -361,10 +361,10 @@ This is the style guide for any **Python project(s)** in this repo.
 - **Disabled markdownlint rules** - repo-specific; `.markdownlint-cli2.jsonc` at the repo root is the source of truth, not any example rule named here.
 - **VS Code config home** - editor **settings/extensions** may live in `.vscode/*.json` **or** the `<Repo>.code-workspace`; **tasks / launch / debug** configs can only be external `.vscode/*.json` (they cannot live in the workspace file). A `[vscode-tasks]` reference must point wherever the repo actually keeps `tasks.json`.
 
-**Two profiles.** A repo's Python is one of two shapes, and the rest of this section (uv project, `uv.lock`, `uv run`, `src` layout, pytest coverage) describes the **project** profile. The two differ by whether the Python has **third-party runtime dependencies**, which shows up structurally in `pyproject.toml`, so the audit detects the profile there (`python.profile.detect`):
+**Two profiles.** A repo's Python is one of two shapes, declared as the `build` or `lint-only` profile and validated against the `pyproject.toml` shape. The rest of this section (uv project, `uv.lock`, `uv run`, `src` layout, pytest coverage) describes the **Project** shape (the `build` profile). The two differ by whether the Python has **third-party runtime dependencies**, which shows up structurally in `pyproject.toml`, so the audit reads the shape there (`python.profile.detect`):
 
 - **Project** - the Python has third-party runtime dependencies, or is the repo's deliverable. It is a PEP 621 uv project: `[project]` with `dependencies` (dev tools in `[project.optional-dependencies]` or `[dependency-groups]`), a `[build-system]`, and a committed `uv.lock` (pinned LF - see [Line Endings][line-endings]); CI runs `uv sync --frozen` + `uv run <tool>`, so the lockfile pins tool versions.
-- **Scripts** - stdlib-only utility scripts embedded in a **non-Python** repo (e.g. a Python tooling subtree of a `csharp` app). Run the tools with **`uvx`** (no project install, no lockfile): the `pyproject.toml` carries **only** tool config (here `[tool.ruff]` plus a `[tool.pyright]` editor block) - no `[project]`, no `[build-system]`, no `uv.lock` (that metadata would misrepresent it as a shippable package). **In this repo** (`easystart/python`, the standalone BLE monitor) **ruff is the only CI gate**, and a `[tool.pyright]` block in **standard** mode keeps Pylance quiet in the editor. There is no mypy gate: the subtree is a single script importing an untyped BLE library, so there is nothing for a second type checker to add over Pylance. CI pins the tool version, **`uvx ruff@0.15.22`**, and the VS Code tasks carry the same pin so the two cannot drift. That pin is a deliberate divergence from the fleet default of running `uvx <tool>@latest` unpinned - the fleet reasons that a manual pin Dependabot does not track goes stale silently, while this repo reasons that an unpinned linter turns an upstream release into a surprise CI failure on an unrelated change. The divergence is raised with the fleet rather than settled locally, so expect this paragraph to move once that is decided. `.py` files follow the repo's line-ending default (LF here - see [Line Endings][line-endings]). There is no pytest suite, so the coverage expectation is N/A.
+- **Scripts** (the `lint-only` profile) - stdlib-only utility scripts embedded in a **non-Python** repo (e.g. a Python tooling subtree of a `csharp` app). Run the tools with **`uvx`** (no project install, no lockfile): the `pyproject.toml` carries **only** tool config (here `[tool.ruff]` plus a `[tool.pyright]` editor block) - no `[project]`, no `[build-system]`, no `uv.lock` (that metadata would misrepresent it as a shippable package). **In this repo** (`easystart/python`, the standalone BLE monitor) **ruff is the only CI gate**, and a `[tool.pyright]` block in **standard** mode keeps Pylance quiet in the editor. There is no mypy gate: the subtree is a single script importing an untyped BLE library, so there is nothing for a second type checker to add over Pylance. CI pins the tool version, **`uvx ruff@0.15.22`**, and the VS Code tasks carry the same pin so the two cannot drift. That pin is a deliberate divergence from the fleet default of running `uvx <tool>@latest` unpinned - the fleet reasons that a manual pin Dependabot does not track goes stale silently, while this repo reasons that an unpinned linter turns an upstream release into a surprise CI failure on an unrelated change. The divergence is raised with the fleet rather than settled locally, so expect this paragraph to move once that is decided. `.py` files follow the repo's line-ending default (LF here - see [Line Endings][line-endings]). There is no pytest suite, so the coverage expectation is N/A.
 
 ### Toolchain
 

ESPHome-Config.code-workspace

@@ -41,7 +41,8 @@
 			"ms-vscode-remote.vscode-remote-extensionpack",
 			"ms-vscode.vscode-serial-monitor",
 			"redhat.vscode-yaml",
-			"streetsidesoftware.code-spell-checker"
+			"streetsidesoftware.code-spell-checker",
+			"xaver.clang-format"
 		]
 	}
-}
+}

OPERATIONS.md

@@ -159,14 +159,14 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
 
 ### Debugging in the DevContainer
 
-- Complete the [VSCode setup](#vscode-setup).
+- Complete the [VSCode setup][vscode-setup].
 - Open the workspace and clone into the devcontainer volume.
 - TODO: serial port forwarding configuration.
 
 ### Debugging on Windows
 
 - Install Python from the Microsoft Store.
-- Complete the [VSCode setup](#vscode-setup).
+- Complete the [VSCode setup][vscode-setup].
 - Compile a project: `esphome compile test/adafruit-esp32-s3-feather.yaml`.
 - Plug in the device, holding Boot and pressing Reset when required.
 - List COM ports from PowerShell:
@@ -191,7 +191,7 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
   - WSL: `ls /dev/tty*`, for example `/dev/ttyACM0`, `/dev/ttyUSB0`
 - Install VSCode and the Remote Explorer extension.
 - Open a VSCode Remote WSL Ubuntu session.
-  - Complete the [VSCode setup](#vscode-setup) in the remote WSL session.
+  - Complete the [VSCode setup][vscode-setup] in the remote WSL session.
   - List ports: `ls /dev/tty*`.
   - Upload firmware: `esphome run --device /dev/ttyUSB0 test/esp32-s3-devkitc.yaml`
 - Unbind the serial port.
@@ -200,7 +200,7 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
 
 ### Debugging in PlatformIO
 
-- Complete the [VSCode setup](#vscode-setup) and install the PlatformIO extension.
+- Complete the [VSCode setup][vscode-setup] and install the PlatformIO extension.
 - Compile the project with `esphome compile [project]`.
 - Launch the PlatformIO extension and open the project folder, for example `./.esphome/build/esp32-s3-test`.
 - PlatformIO opens a new instance of VSCode for that project.
@@ -226,12 +226,13 @@ The steps below run ESPHome outside the live instance, on a workstation, which i
 [garage-presence-sensor]: ./garage-presence-sensor.yaml
 [templates]: ./templates/
 [test-workflow]: ./.github/workflows/test-pull-request.yml
+[vscode-setup]: #vscode-setup
 
 <!-- External -->
 
 [dashboard-link]: http://localhost:6052/
-[esp-idf-framework-link]: https://esphome.io/components/esp32#esp-idf-framework
-[esphome-cli-link]: https://esphome.io/guides/cli
+[esp-idf-framework-link]: https://esphome.io/components/esp32/#esp-idf-framework
+[esphome-cli-link]: https://esphome.io/guides/cli/
 [esphome-nonroot-link]: https://github.com/ptr727/ESPHome-NonRoot
 [espressif32-versions-link]: https://registry.platformio.org/platforms/platformio/espressif32/versions
 [framework-espidf-link]: https://registry.platformio.org/tools/platformio/framework-espidf