caseworkctl check accepts a policy package whose manifest no longer matches

### What we hit

`caseworkctl package` writes the policy, the exact imported source descriptions, and `casework.package.json` with their digests. The `casework` runtime rebuilds the manifest at startup and refuses any difference with `casework: the Casework policy package is invalid` (observed for one added blank line in `casework.yaml` and for an unrelated file dropped into the package root).

`caseworkctl check` run against that same package directory reports `"ok": true`. It checks the policy, not the manifest, so an author who edits a packaged file in place gets a green check and learns about the mismatch only when the operator's restart fails.

### Where it maps

- `crates/registry-caseworkctl/src/project.rs`: `check` and `package`.
- `crates/registry-casework`: the startup manifest verification the runtime performs.

### Ask

When `caseworkctl check` is pointed at a directory containing `casework.package.json`, verify the manifest with the same rule the runtime applies (every listed file present with its digest, no extra file beside them) and report the first difference by file name, before the policy checks. Keep the plain-project path unchanged. The configure how-to currently warns about this under a caution; that sentence can go once the check reports it.

Start in crates/registry-caseworkctl/src/project.rs, reading the check and package paths, then compare them with the startup manifest verification in crates/registry-casework. Done means packaged directories reject missing, changed, or extra files with the first differing file named, while plain-project checks remain unchanged; remove the obsolete configure how-to caution.

Written by the indexing model from the issue text.