CI tests the ceiling of the declared dependency ranges

## Summary

Add a CI job that resolves the runtime dependencies at `--resolution
highest`, ignoring `poetry.lock`, and runs the suite against them. This
covers the upper edge of the declared ranges, which nothing tests today.

## Motivation

The `dependency-floor` job covers the lower edge of `click = "^8.2"` and
`click-log = "^0.4.0"`. `poetry.lock` covers exactly one point in the
middle, currently click 8.4.2. Nothing covers the top, which is where a
newly published release lands.

That edge is not hypothetical, because a downstream packager is already
standing on it. The nixpkgs derivation
(`pkgs/by-name/zf/zfs-replicate/package.nix`) builds from the git tag and
runs the suite with its own `python3Packages`, ignoring `poetry.lock`
entirely. Downstream therefore discovers a breaking dependency release at
their build time rather than ours, on a package this project's author
also maintains in nixpkgs. A ceiling job moves that discovery upstream to
where it can be fixed before a release ships.

## Scope

- Add a `dependency-ceiling` job to `.github/workflows/ci.yml` mirroring
`dependency-floor`, resolving with `--resolution highest` rather than
`lowest-direct`.
- Decide whether it blocks or runs advisory. Unlike the floor, this job
can turn red from an upstream release with no change in this repo, so
it behaves more like the existing `experimental: true` matrix leg than
like a gate.

## Acceptance criteria

- [ ] The job's resolved runtime versions differ from `poetry.lock`
whenever a newer satisfying release exists, visible in the job log
- [ ] The blocking-versus-advisory decision is recorded as a comment in
`ci.yml`, so the next reader does not have to re-derive it

## Additional context

Both jobs come out of the same question: the sdist ships
`pyproject.toml` and no lock, so the declared ranges are the only version
signal a packager receives, and a range is only a contract if something
tests its edges.