Track public free functions: keep, migrate to natural receivers, or retire compatibility wrappers

## Goal

Track every supported public free function in `zenpixels` and `zenpixels-convert`, and give each one an explicit disposition. Method syntax is useful only when an operation has a natural receiver; the goal is **not** to replace coherent module-level algorithms with one-off extension traits.

Semver policy:

- Existing free functions remain as deprecated compatibility wrappers through 0.2.x when a replacement is introduced.
- Removal happens only in the queued 0.3.0 batch and must also be listed in `CHANGELOG.md`.
- Pure behavior fixes are allowed, but receiver migrations must not force consumers to change immediately.
- Do not add a trait solely to make one function look like a method. Prefer an inherent method on a crate-owned plan/configuration/result type; use a sealed extension trait only for a type owned by another crate.
- Hidden benchmark/test hooks and crate-internal functions are out of scope.

This inventory is relative to the public surface in/after PR #63.

## Already decided and implemented on the #63 branch

- [x] `convert_row(plan, ...)` → `ConvertPlan::convert_row(...)`; keep the free function as a deprecated wrapper until 0.3.
- [x] `orient::{apply_orientation, apply_orientation_into, apply_orientation_in_place}` → sealed `PixelSliceOrientationExt` / `PixelBufferOrientationExt` receiver methods; keep the three published wrappers until 0.3. The unreleased `into_oriented` helper was removed before publication.
- [x] `adapt::convert_buffer` is deprecated; use `PixelBufferConvertExt::{convert_to, convert_into, convert_in_place}`, then remove in 0.3.
- [x] `cms_moxcms::{lut_transform_opts,cicp_transform_opts}` are deprecated aliases for `transform_opts`; remove in 0.3.
- [x] `icc_profiles::icc_profile_for_primaries` is deprecated; prefer `synthesize_icc_for_cicp` or an explicit bundled profile; remove in 0.3.
- [x] `hdr::{reinhard_tonemap,reinhard_inverse,exposure_tonemap}` are deprecated in favor of zentone; remove in 0.3.
- [x] Legacy `adapt_for_encode*` functions returning `Adapted` are compatibility wrappers; use the corresponding `*_cow` functions returning `PixelCow`, then remove `Adapted` and its wrappers in 0.3.

## Keep as module functions

These are stateless algorithms, lookups, parsers, or mathematical transforms. Moving them to traits would obscure rather than clarify ownership.

### `zenpixels::icc`

- [ ] Keep `extract_cicp`, `identify_common`, `is_common_srgb`, and `profile_color_space` as namespaced parsing/query functions.

### `zenpixels::registry`

- [ ] Demote `find_by_cicp`, `find_by_primaries_transfer`, and `find_by_named` to `pub(crate)` in 0.3 as already queued.
- [ ] Keep `rgb_to_xyz`, `gamut_matrix`, `mul_mv`, `mul_3x3`, and `invert_3x3` as mathematical module functions if they remain public. Do not create matrix or primaries extension traits merely for method syntax.

### `zenpixels-convert::{gamut,fast_gamut,oklab}`

- [ ] Keep matrix application/composition, linear RGB conversion, Oklab conversion, matrix lookup, and `fast_cbrt` as module functions. These are conventional stateless math APIs with no single compelling receiver.
- [ ] Avoid duplicating these functions on extension traits.

### ICC profile construction

- [ ] Keep `display_p3_icc`, `synthesize_icc_for_cicp`, and `synthesize_gray_icc_for_cicp` as namespaced constructors.
- [ ] Do not add a `Cicp` extension trait solely for ICC synthesis. If a cohesive crate-owned builder/configuration type appears later, reconsider associated constructors there.

## Defer until the negotiation design exists

The current adaptation helpers accept a source plus a caller-provided candidate list. They do **not** inspect actual encoded data, codec configuration, or content-dependent codec support, so they are not general codec negotiation.

- [ ] Keep `adapt_for_encode_cow`, `adapt_for_encode_with_intent_cow`, and `adapt_for_encode_explicit_cow` as free functions for now.
- [ ] Keep `negotiate`, `best_match`, `best_match_with`, `ideal_format`, `conversion_cost`, and `conversion_cost_with_provenance` as free functions for now.
- [ ] Design the future API around a crate-owned negotiation context/plan that can represent:
- actual pixel data and descriptors;
- decodable encoded-image properties;
- codec capabilities under a specific configuration;
- caller policy and conversion intent;
- provenance/content-dependent constraints.
- [ ] Only then consider associated methods such as `NegotiationPlan::choose` / `cost` and deprecate redundant free functions. Do not introduce adaptation extension traits in advance of that design.

## Natural receiver exists, but placement needs design

### In-place adaptation

- [ ] Evaluate moving `try_adapt_in_place(&mut PixelBuffer, target)` onto the existing conversion capability surface rather than creating a new trait.
- [ ] Preserve its narrower, explicitly lossless/metadata-aware semantics; do not imply that it is equivalent to arbitrary conversion.
- [ ] If no intuitive name fits the existing trait, keep it free rather than proliferating traits.

### Output finalization

- [ ] Keep `finalize_for_output_with` until a cohesive crate-owned `OutputPlan` / `OutputOptions` exists.
- [ ] Prefer inherent operations on that plan/configuration over another `PixelBuffer` extension trait: finalization consumes origin metadata, target profile, pixel format, CMS configuration, and later HDR policy, so the pixel buffer is not the sole conceptual receiver.
- [ ] `finalize_for_output` is already deprecated in favor of `finalize_for_output_with`; remove it with `ColorManagement` in 0.3.
- [ ] Once the plan type exists, add allocation-reusing consuming/into variants and deprecate the free wrapper only when there is a complete replacement.

### HDR quantization

- [ ] Keep `hdr::quantize_to` namespaced while HDR/output policy is still being consolidated.
- [ ] Do not add another slice extension trait for this one operation.
- [ ] Reassess as an `OutputPlan`/HDR-plan method when the anchored HDR pipeline (#45/#39) has a concrete consumer.

### Pipeline analysis

- [ ] Keep `pipeline::{optimal_path,generate_path_matrix,matrix_stats}` free while the pipeline module remains a set of stateless analyses.
- [ ] If shared registry/policy/configuration state becomes real, introduce one cohesive `PathPlanner` and move all three to inherent methods/associated functions together. Do not create three extension traits.

## Feature-specific constructor

- [ ] Keep `cms_moxcms::transform_opts(priority, intent)` as a namespaced constructor for now. `TransformOptions` is owned by moxcms, so an inherent method is unavailable and a one-method extension trait is not justified.
- [ ] Revisit only if zenpixels-convert gains its own CMS configuration type.

## Completion criteria

- [ ] Every public free function added later receives a disposition here during API review.
- [ ] All migrations provide a clearly better replacement before deprecation.
- [ ] Deprecated wrappers and their replacements are cross-linked in rustdoc.
- [ ] Every planned removal appears in the changelog’s canonical 0.3 removal inventory.
- [ ] `cargo semver-checks` shows no new break caused by a migration.
- [ ] Public API snapshots and examples present receiver methods as canonical where a migration has landed.

Related: #39, #45, #64, #66, #67, #68, #69, #70.

Start with the public API surface in and after PR #63, then work through the unresolved dispositions in this issue and the planned removals in CHANGELOG.md. Check the affected rustdoc links, API snapshots, examples, and cargo semver-checks; done means every later public free function has a disposition, replacements are documented, and the completion criteria are met.

Written by the indexing model from the issue text.