pull,package_info,ui,cli: report the pull flow via BuildView

Retire the ProgressCallback option-of-closure, the one pre-port
reporting idiom left in the tree: pull and package_info::lookup now
take &dyn BuildView like every other core flow, and the announcements
map onto message (unsized work), progress (item counts: series probes,
git objects, extraction) and progress again for byte downloads, which
the old callback carried in the same 4-argument shape.

The terminal side swaps the (ProgressBar, closure) pair for PullView, a
BuildView implementation owning one bar of the shared MultiProgress
with the same spinner/transfer style switching; it releases the line on
drop, which the CLI triggers explicitly on both outcomes since
exit(1) skips destructors. Headless callers (tests, internal lookups)
pass &report::Quiet. git clone sideband parsing is skipped entirely
when the view is not enabled, matching the old None-callback shortcut.

src/report.rs

@@ -68,10 +68,12 @@ pub struct BuildTarget<'a> {
 /// Observer of a running build: target identification, phases, status
 /// messages, progress and the final outcome.
 ///
-/// Implement this to observe the [`crate::build`] and [`crate::deb`] flows
-/// from any frontend. All events arrive in order from the build thread;
-/// long-lived views are expected to be `Send + Sync` because builds may run
-/// inside async tasks.
+/// Implement this to observe the [`crate::build`], [`crate::deb`] and
+/// [`crate::pull`] flows from any frontend. All events arrive in order from
+/// the build thread; long-lived views are expected to be `Send + Sync`
+/// because builds may run inside async tasks. The pull flow only emits the
+/// [`BuildView::message`], [`BuildView::progress`] and
+/// [`BuildView::progress`] events — no target, phases or outcome.
 pub trait BuildView: Send + Sync {
     /// The build target was identified; the events that follow belong to it
     /// (including the earliest subprocess output, e.g. a chroot download).