fix(data list): text datasets showed no size (du measured disk blocks; zero == unknown)

[shujaatTracebloc]

Closes #491. Found from a live Windows cluster: every text dataset showed no size, while image
datasets in the same namespace showed real ones.

Root cause — two defects that compound

1. The size was mis-measured. Sizes come from du -sk <shared>/* run inside the jobs-manager
pod. Without --apparent-size, du measures st_blocks, and on a bind-mounted host filesystem
(Docker Desktop, and any mount that doesn't report block allocation for small files) that returns
0 for a directory of small files. Measured on the affected node:

0     <shared>/mlm_train
0     <shared>/text_train
180   <shared>/image_train

Image datasets survive only because their files are large enough to occupy reported blocks. Text
datasets are dozens of small .txt documents, so every one of them measures zero.

2. Zero and "unknown" were the same value. sizeCell gated on SizeBytes > 0, so a dataset
measured at 0 was indistinguishable from one the CLI never managed to measure. That's why this
presented as "the size is missing" rather than "the size is wrong" — and why it looked like a
broken lookup when the lookup was working fine.

Tabular/time-series datasets hid defect 1 by accident: their empty Extension routes them to
DBBytes instead of du.

The change

• Probe --apparent-size once, then pass it to a single du run. Deliberately not
  du --apparent-size … || du …: du exits non-zero if any path is unreadable, so that chain
  would silently fall back to block sizes whenever one dataset dir was inaccessible —
  reintroducing this bug intermittently, which is harder to diagnose than never having the flag.
  A test pins that the real du runs exactly once.
• DatasetInfo.SizeKnown separates "measured" from the value. A measured zero renders 0 B;
  only a failed lookup renders —.
  SizeKnown rather than an inverted SizeUnknown on purpose: if a producer ever forgets the
  flag, rendering — understates what we know, whereas the inverted field would assert a
  confident 0 B that is false.

Verification

• go test ./... — 16 packages ok. 4 new tests, and both guards verified to fail when
  their own defect is reintroduced.
• The copy-catalog golden is unchanged, which is the point: measured datasets render exactly as
  before, and only genuinely-unknown ones change.
• gofmt -s, goimports -local, go vet, errcheck, staticcheck -checks all,-ST1005 clean.

Two notes for the reviewer, in the interest of not overstating this:

• My first pass annotating fixtures missed the two in copy_catalog_test.go (they end in }, not
  ,), and the regenerated golden showed — where real sizes belong. Reviewing that diff caught
  it — I reverted the golden and fixed the fixtures rather than accepting the drift. Worth knowing
  that TB_UPDATE_GOLDEN=1 will happily bake in a regression if you don't read it.
• The commit message's closing line about bumping VERSION to 0.10.6 is inaccurate — no bump
  is in this diff. develop moved to 0.10.5 via fix(interactive): show Windows path examples on Windows (client#615) #487 while I was working, and v0.10.5 isn't
  tagged, so version-bump-gate passes without one. I left the message rather than force-push a
  correction.

The du change itself runs inside the jobs-manager container, which is where I can't reach — so
the apparent-size behaviour is reasoned from st_size vs st_blocks plus the node measurements
above, not observed in that pod. Worth one tb data list on a Windows cluster to confirm text
sizes appear.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes the remote du command run inside jobs-manager and adds a field to the data-list JSON contract. Well-covered by tests, but sizing behavior depends on container du support and should be spot-checked on a Windows cluster.

Overview
Fixes #491 where text datasets rendered as sizeless on bind-mounted host filesystems (e.g. Docker Desktop on Windows), while image datasets looked fine.

Measurement: du on the shared PVC now probes for --apparent-size and uses it when available, so sizes come from st_size instead of disk blocks that report 0 for small files. The real du still runs once (no || fallback that could silently revert to block sizes).

Display/API: Adds SizeKnown so a measured 0 renders as 0 B (and JSON size_known: true) instead of conflating with unknown (— / unmeasured). The same flag is exposed in --output-json details.

^{Reviewed by Cursor Bugbot for commit 3e4e10c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saadqbal]

Nice, careful PR 👍 The zero-vs-unknown model holds in every path (measured/measured-zero/unmeasured file dataset, row-based, empty table), table and JSON agree via the same SizeKnown, and probing --apparent-size once instead of a || du fallback is exactly right. Tests are non-vacuous and both guards fail when their defect is reintroduced. go test ./internal/cli ./internal/push green locally. One nit, non-blocking: du -sk rounds apparent size up to KiB, so the sub-KiB "512 B" case only exists in the sizeCell unit test, never from a real measurement — fine, just noting the rendering path is exercised where du never lands it.