Changeset convention: which packages a changeset should list is unwritten

**Type:** chore / docs · **Raised in:** PR #4305 review by @rkihm-BC

## The inconsistency

Two PRs doing the same thing listed different package sets:

| PR | Source changed | Manifests regenerated | Changeset front matter |
|---|---|---|---|
| #4275 (#4260) | `core-entities-server` | `server-bootstrap`, `server-bootstrap-lite` | **1 package** |
| #4305 (#4282) | `core-entities-server` | `server-bootstrap`, `server-bootstrap-lite` | **5 packages** |

Verified against `d0eab882c4`, whose own commit message says it regenerated both bootstrap
manifests — so this is the same situation resolved two different ways, not two different
situations.

## Why the rule file does not settle it

`.claude/rules/changesets.md` is thorough about bump *levels* and deliberately silent on
membership. It also explains why membership carries no semver signal: all ~300 packages share one
`fixed` group, so the highest level in a release decides the tuple for every package and a
consumer already receives bumps driven by packages they do not use.

So membership decides exactly one thing: **whose `CHANGELOG.md` the entry lands in.** That is a
real question — someone reading `server-bootstrap`'s changelog to find out why its manifest moved
gets an answer under #4305's convention and nothing under #4275's — but it is not the question the
existing rule answers.

## Proposal

Add a short "Which packages to list" section to `.claude/rules/changesets.md`:

> List every package whose **tracked files the branch changes**, generated manifests included. The
> level is release-wide and identical for all of them; membership only decides which package
> changelogs carry the entry, and a regenerated file with no changelog line is a change nobody can
> trace.

Naming the reasoning matters as much as the rule, since the natural (wrong) inference is that the
list is about semver.

Not proposing any change to #4275 — it is merged and its changeset is consumed.