What this is

lfind searching a target that is still in service, by consuming the Object
Stream the in-kernel scanner of LU-20720 produces, instead of reading the
target as a device.

What already exists

LU-20611 separated find's predicates from find's traversal, so
llapi_find_device() runs them over objects from llapi_scan_device()
rather than a namespace walk, with lfind(8) on top.
llapi_scan_device() selects a backend at run time. Two exist, ldiskfs and
ZFS, both reading a target that is out of service, and both loaded as plugins
behind one five entry point interface.

The prototype consumer of the kernel scanner implements that same interface, so
this is mostly connecting two halves that already match.

What changes

A third backend, selected when the named target is in service, reading the
Object Stream from the kernel module instead of the device. It compiles the
predicates into the filter the kernel evaluates and hands them over before the
first record, so what arrives is already the answer and nothing is re-evaluated
in userspace. It checks the stream's version and record size before trusting a
record. It reports which attributes the module can serve, so a filter the
kernel cannot answer is refused rather than silently matching nothing. Thread
count is not a knob here: parallelism stays behind the enumerator in the
kernel.

What does not change

Nothing above llapi_scan_device(). The predicate set,
llapi_find_device(), lfind(8), the pathname options, the record and the
manual pages are untouched. The same command that searches a stopped target
searches a running one.

Why it is worth doing before the client side

Two reasons beyond being a usable tool.

It is the only practical correctness oracle for LU-20720. With a device
backend and a kernel backend behind one interface, the same quiescent target
can be scanned both ways and the two answers compared object by object. Neither
scanner has that check alone, and without this ticket LU-20720's main
differential test waits on the transport of LU-20721.

It also exercises the Object Stream API before a client depends on it. The
HLD has the client consume the stream through the same kernel API the OSD
produces it with, so proving that API against a local consumer first takes a
piece of risk out of LU-20721 rather than discovering it across a wire.

Scope

In scope: the backend and its selection rule; the diagnostic for a target that
is in service when the module is not loaded, which must say so rather than
reporting that no backend exists; lfind on a mounted target and its manual
page; and tests, including the differential run above.

Not in scope: the client side, which is LU-20721; and the scanner itself, which
is LU-20720.

Risk

Not a crash, but a silent difference in which objects match between a target
scanned as a device and the same target scanned through the kernel. The
differential test is the control for exactly that, and it is cheap because both
paths are then in the tree.