feat(cli): use the wildcard cluster read in tree -L 4

[p0fi]

Summary

• Replace the per-attribute read loop in treePopulateAttributes with one wildcard attribute read per cluster, collapsing tree -L 4 from 1 + N round-trips per cluster to 1
• Level 3 is unchanged: it still uses the cheap AttributeList-only read since it only needs names, not values
• The AttributeList discovered in a level-4 wildcard read's reports write-throughs into the attribute-name completion cache the same way the old dedicated read did
• A transport failure now fails the whole cluster (TreeCluster.ListErr), while a per-attribute status inside a successful wildcard read stays scoped to that one attribute (TreeAttribute.Err)
• Devices that under-report their own AttributeList now show what they actually return in tree -L 4, rather than being filtered to the advertised list

Closes #89.

Test plan

• mise run test — full suite passes
• mise run lint — clean
• New/updated table-driven tests in cli/attribute_cache_test.go cover: level-3 AttributeList-read path unchanged, level-4 wildcard read populating attrs + caching AttributeList, a failed wildcard read keeping the stale cache and reporting ListErr, a per-attribute status inside a successful wildcard read not failing the cluster, and a device omitting AttributeList from its wildcard response leaving the cache untouched
• End-to-end verification against the matter.js virtual device (wall-clock tree -L 4 comparison before/after) — not yet run, flagging for manual follow-up

[p0fi]

End-to-end verification (matter.js virtual device)

Commissioned matter.js's examples-device-onoff (13 clusters across 2 endpoints) and ran tree -L 4 against it with two builds: HEAD of this PR (f9e6477) vs the pre-#89 baseline (32a2143, the merge-base with main).

Wall-clock (3 runs each, localhost — negligible RTT so this is a worst-case floor for the win):

	run 1	run 2	run 3
baseline (32a2143)	186ms	172ms	154ms
this PR (f9e6477)	105ms	99ms	89ms

~40–45% faster even with near-zero network latency, purely from cutting round-trips per cluster from 1 + N to 1. Over Thread/congested Wi-Fi, where each round-trip carries real RTT instead of ~0, the win scales with N and should be much larger — that's the scenario the issue describes.

Output correctness: diffed full tree -L 4 output between the two builds. Identical modulo:

• Live device counters that legitimately changed between runs (UpTime, diagnostics counters)
• Bitmap attributes (FeatureMap, NameSupport) now show the binary breakdown (e.g. 1 (0b1)) — a side effect of reusing buildReadRecords/formatAttrValue from Read All Attributes From a Specific Cluster #82 instead of the tree's old ad hoc decoder, which didn't have that formatting
• Null-valued attributes now render as <empty> instead of <no data> — same reuse, same reason

Completion cache write-through: after running tree -L 4, matter OnOff read @1/1 <TAB> completion is scoped to exactly the 10 attributes the device's wildcard-read AttributeList advertised — confirming the level-4 wildcard read's AttributeList still feeds the completion cache correctly (open question 1 in the issue).