docs(avhw): fix misleading Send soundness reasoning

Oracle audit of all 5 `unsafe impl Send` in src/avhw/ found soundness
intact but reasoning wrong in 3 of 5:

- AvHwDevCtx: claimed '&mut self ensures exclusive access' — false,
  ref_clone() hands raw pointers to other threads / FFmpeg-internal
  codec workers. Real basis is AVBufferRef atomic_uint refcount +
  libva VADisplay thread safety.
- AvHwFrameCtx: claimed 'send/receive pattern is thread-safe' —
  misdirection. Real basis is AVBufferPool atomic get/put.
- EncState: claimed 'raw pointers not shared across threads' — false
  when FFmpeg frame/slice threading is enabled. Real basis is the
  hw device/frames contexts being designed for such sharing.

SwEncState and SwEncEncode comments were acceptable; improved for
clarity (note that contained FFmpeg handles are non-thread-safe but
Send-sound under exclusive access, and that crossbeam/Arc fields are
already Send by design).

Added module-level convention doc to src/avhw/mod.rs centralizing
the C-API-level justification rule and explicitly calling out the
'&mut self as Send basis' anti-pattern so future contributors don't
repeat the category error.

Fixed AGENTS.md:
- Stale claim that Cargo.toml 'only warns' on undocumented_unsafe_blocks
  (it's been 'deny' for a while)
- Stale path src/avhw.rs → src/avhw/ (split in d53e881)
- Stale 'avoid moving wrappers across threads' guidance — Send is sound,
  the audit just confirmed why

No code behavior change. Verified: cargo build --release,
cargo clippy --release --all-targets (0 warnings),
cargo test --release (79 unit + 3 integration, 1 ignored).

src/avhw/encode.rs

@@ -53,8 +53,11 @@ pub struct SwEncEncode {
 /// MP4 mode keeps 1/fps time_base for file output simplicity.
 pub const WEBRTC_RTP_CLOCK_HZ: i128 = 90_000;
 
-// SAFETY: SwEncEncode owns sws_ctx/yuv_frame/enc_video exclusively after construction.
-// It is moved to a single encode thread and only accessed through &mut self there.
+// SAFETY: SwEncEncode is moved to a single encode thread and accessed only there
+// via &mut self. SwsContext, AVFrame, and AVCodecContext are NOT thread-safe for
+// concurrent access but are Send-sound under single-thread exclusive use, which
+// the encode worker invariant provides. crossbeam Receiver and Arc<AtomicBool>
+// are Send by design.
 unsafe impl Send for SwEncEncode {}
 
 impl SwEncEncode {