- refdb_backend: the iterator callback documents `out` for an argument
  named `iter`; unlock documents `who`, which is the name `rename`
  uses, while unlock itself takes `sig`
- utf-conv: git_utf8_from_16 documents `src_len`, an argument only
  git_utf8_from_16_with_len has
- path_w32: both trim_end and remove_namespace document `path` for an
  argument named `str`
- w32_util: filetime_to_timespec documents `FILETIME`, the type, where
  the argument is `ft`

Comments only.

…fig-parse-int64

`inflate()` reports `Z_BUF_ERROR` when a truncated stream exhausts
its input before reaching `Z_STREAM_END`.

The stock `zstream_seterr` suggests treating that as non-fatal
so callers can retry with more input or output space.

However,
the drain loop in `git_zstream_get_output` can supply neither because

* output space is still available
* input is only refilled outside the loop

It would leads to zero-progress forever.

The problematic behavior was found in `git_odb_read`
on a truncated loose object.

The proposed fix here:
Detect the stuck state in the drain loop and report an error.

When inflating a stream,
if the stream is truncated midway,
it must fail rather than loop forever.

This ensure that `git_odb_read` fails
when reading truncated loose object.

If you move this before the fix commit,
this loops forever

Takes inspiration from 346f28b

Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>

CVE-2026-5917: Escape repo path in gen_proto()

…gnatures

docs: fix six @PARAM names that do not match the signatures

fix(zstream): fail on truncated input instead of looping forever