v0.2.3

Fixed

• Composite paths no longer drop backend-specific keyword arguments.
  CompositePosixPath.symlink_to() accepted only the stdlib signature and
  forwarded nothing else, so a backend's documented extension was unreachable
  through the very abstraction meant to expose it — a path obtained from
  host.path() raised TypeError: unexpected keyword argument 'force' even
  when the selected backend implemented force=.

  Forwarding is signature-aware rather than blind: the selected backend's
  method is inspected, and only keywords it declares are passed through.
  Anything else still raises TypeError at the composite boundary, naming
  the backend class and the rejected keyword. Blind passthrough would have
  turned a clear error at the abstraction boundary into a confusing one from
  inside a transport, and the existing contract — a backend lacking a
  capability raises NotImplementedError, never a silent no-op — is
  unchanged. A method whose signature cannot be introspected (a C function,
  a functools.partial) receives the keywords, since an error from it is no
  worse than calling it directly.

  Applied to mkdir(), chmod(), unlink(), and rmdir() alongside
  symlink_to(), since the same normalization affected each of them.

  This pairs with pathlib_next's symlink_to(force=), which that project
  exposes as a generic Path extension over a _symlink_to() backend
  primitive. No version floor change: hostctl's pathlib_next>=0.8.6 floor
  stays where it is, so force= is forwarded when the installed version
  provides it and rejected at the boundary when it does not.

Full Changelog: v0.2.2...v0.2.3