install-tools.sh --repo dies on a host-tools.json with zero install.linux entries

[ptr727]

Summary

host-setup/linux/install-tools.sh --repo PATH dies on a host-tools.json that declares
tools but zero install.linux entries, instead of treating "nothing to add" as a no-op.

Found while wiring HomeAutomation-Config to reference this script directly instead of
vendoring a copy (thin wrapper always passing --repo <checkout>). That repo's
host-tools.json is scripts/host_gate.py-style version-floor metadata only — no tool in
it declares install.linux — which hits this bug on every run.

Where

load_repo_tools() in host-setup/linux/install-tools.sh, tested at commit
2e0b1309699949af286b00bbae31b23455b805e3:

rows=$(jq -r '...' "$declaration") ||
    die "Cannot read constrained Linux install metadata from $declaration"
while IFS=$'\t' read -r name manager package; do
    [[ -n $name ]] || die "$declaration carries Linux install metadata without a non-empty tool name"
    ...
done <<< "$rows"

When no .tools[] entry has .install.linux, the jq filter produces no output, so rows
is the empty string. <<< "$rows" still feeds the while read loop one line (a here-string
always appends a trailing newline, even for an empty string), so the loop runs once with
name/manager/package all empty and immediately dies on the "non-empty tool name" check
-- even though the declaration is otherwise valid and simply has nothing to add.

Repro

mkdir -p /tmp/repro && cat > /tmp/repro/host-tools.json <<'EOF'
{
  "tools": [
    { "name": "some-probe-only-tool" }
  ]
}
EOF

./host-setup/linux/install-tools.sh --report --repo /tmp/repro

Expected: reports normally, since the repo declares no install.linux packages to layer in.

Actual:

ERROR: /tmp/repro/host-tools.json carries Linux install metadata without a non-empty tool name

Suggested fix

Guard the loop on an empty $rows before entering it, e.g.:

[[ -n $rows ]] || return 0

placed right after the rows=$(jq ...) assignment, before the while loop.

Workaround in use

HomeAutomation-Config's wrapper only passes --repo when host-tools.json actually has an
install.linux entry to offer (checked with a small jq -e probe before invoking this
script), so it's unaffected today. Tracked there to drop the workaround once this is fixed.