AVIF path: complete ravif↔zenrav1e 0.2 whereat migration (publish-gated)

The zenpipe full-workspace CI is red on **`zenravif`** (the AVIF encoder, sibling `imazen/cavif-rs`), not on zencodecs/HDR (zenpipe#68 is clippy-clean). Root cause + the verified fix:

### Cause — in-flight zenrav1e 0.1→0.2 migration
- zenrav1e `master` is **0.2.0**, returning whereat-traced config errors (`At`).
- ravif (cavif-rs) PR #5 migrated its public API to `At` + reason preservation but stayed on **zenrav1e 0.1.4**, with a documented TODO at the three `new_context()` sites to switch to the 0.2 trace-carrying form.
- Under the sibling-assembly, ravif #5 compiles against zenrav1e 0.2.0 → `Error: From>` not satisfied → CI break. (Also: zenavif still expects bare `ravif::Error`, broken by #5's `At`.)

### Verified fix (ravif side) — preserve + annotate
At each `new_context()` site:
```rust
.map_err(|e| e.map_error(Error::from).at_crate(crate::at_crate_info()))?
```
`map_error` keeps zenrav1e's trace (via the existing `From`); `at_crate` annotates ravif's boundary. Verified against sibling zenrav1e 0.2.0: 24 lib tests + `clippy -D warnings` + a regression test (asserts the source frame is preserved AND the `crate: zenravif` annotation is present). Patch: `/mnt/v/ravif-whereat-0.2-fix.patch`.

### Blocker — publish coordination
zenrav1e 0.2.0 is unpublished and its dep chain (`av-scenechange` …) doesn't resolve standalone, so bumping ravif's `zenrav1e` to 0.2.0 breaks ravif's own CI (only the sibling-assembly resolves it) — exactly why #5 deferred it. Landing sequence:
1. Publish zenrav1e 0.2.0 (+ deps) to crates.io.
2. Apply the patch to ravif, bump `zenrav1e = "0.2.0"`, publish zenravif 0.2.0.
3. Sync zenavif to `At` (preserve trace via `full_trace()`/`.error()`), bump its dep.

Until that publish chain lands, the AVIF path only builds under sibling-assembly and this stays red. **Not** caused by, and independent of, the zencodecs/HDR corpus work (zenpipe#68).