ci: pin the CI badge to develop and gate the lockfile (#93)

Fixes the red CI badge, a second badge that was about to break silently,
and adds the lockfile guard.

## The badge was lying

The badge tracked the default branch. Moving the default to `develop`
pointed it at a branch with no completed run yet, so GitHub fell back to
the most recent run of the workflow overall - which was this:

```
release-please--branches--develop--components--mcp-windbg
  pull_request  completed / action_required   actor: github-actions[bot]
```

A permanently blocked run, never executed, awaiting an approval nobody
will give. Every real run was green. Pinning the badge to
`?branch=develop` makes it deterministic and immune to runs on PR
branches; it now reads **passing**.

**On whether CI is needed on the release PR: no.** That PR only bumps
version fields and the changelog, and `publish-mcp.yml` runs the full
matrix before anything ships, so the gate already exists downstream.
Worth knowing that the blocked run cannot be filtered away:
`pull_request` `branches:` filters the *base* branch, not the head, so
there is no trigger-level way to exclude `release-please--**`. A
job-level `if` would not help either, since the run is blocked at
approval before job conditions are evaluated. It is inert and now
cosmetically irrelevant.

## The Docs badge was about to freeze

Quieter version of the same problem, introduced by #90. `pages.yml` is
now invoked through `workflow_call`, and a called workflow does not
produce its own top-level run - so its badge would have stayed pinned to
the last direct push to `main` forever, showing "passing" no matter what
happened. It now reads the `github-pages` deployment, which is the thing
actually being asserted.

## Lockfile guard

```yaml
- name: Check uv.lock is in step with pyproject.toml
  run: uv lock --check
```

Placed *before* `uv sync`, which would otherwise refresh the lockfile
and hide the drift. release-please has no updater for `uv.lock`, and it
sat a full release behind at 1.0.1 before anyone noticed.

## Verification

- `build-and-test.yml` parses; `uv lock --check` passes on this branch.
- Pinned CI badge renders `CI - passing`; the deployments badge renders
`docs: success`.

Author: svnscha

.github/workflows/build-and-test.yml

@@ -42,6 +42,12 @@ jobs:
     - name: Set up Python ${{ matrix.python-version }}
       run: uv python install ${{ matrix.python-version }}
 
+    # uv.lock is not something release-please knows how to update, so it went
+    # stale for a whole release once without anything noticing. `uv sync` would
+    # quietly refresh it, so check before syncing, not after.
+    - name: Check uv.lock is in step with pyproject.toml
+      run: uv lock --check
+
     - name: Install dependencies
       run: uv sync --dev
 

README.md

@@ -1,7 +1,7 @@
 # MCP Server for WinDbg Crash Analysis
 
-[![CI](https://github.com/svnscha/mcp-windbg/actions/workflows/ci.yml/badge.svg)](https://github.com/svnscha/mcp-windbg/actions/workflows/ci.yml)
-[![Docs](https://github.com/svnscha/mcp-windbg/actions/workflows/pages.yml/badge.svg)](https://svnscha.github.io/mcp-windbg/)
+[![CI](https://github.com/svnscha/mcp-windbg/actions/workflows/ci.yml/badge.svg?branch=develop)](https://github.com/svnscha/mcp-windbg/actions/workflows/ci.yml)
+[![Docs](https://img.shields.io/github/deployments/svnscha/mcp-windbg/github-pages?label=docs)](https://svnscha.github.io/mcp-windbg/)
 [![PyPI](https://img.shields.io/pypi/v/mcp-windbg)](https://pypi.org/project/mcp-windbg/)
 [![License: MIT](https://img.shields.io/badge/License-MIT-blue.svg)](LICENSE)
 ![Platform: Windows](https://img.shields.io/badge/platform-Windows-0078D6)