fix(pools): the port guard keys on length, so say length (#405)

[VijitSingh97]

Follow-up to #406, which I merged before its review reached me. No closing keyword — see #406 for
why that is deliberate in this repo. #405 is already closed against #406 and #408.

What is wrong

The guard is correct and stays as it is. Two artefacts describing it are not, and one of them is
operator-facing.

_validate_host_port tests [ "${#_p}" -gt 5 ] — digit count, nothing else. The CHANGELOG, the
in-code comment and the test names all said "zero-padded port", which is a different and wider
property. Measured against the shipped validator rather than reasoned about:

065535   rejected      (six digits — trips the cut)
08080    ACCEPTED      (padded, five digits)
00080    ACCEPTED      (padded, five digits)
080      ACCEPTED      (padded, three digits)
999999   rejected, and told to remove padding it does not have

That last line is why this is not a docs-only change. A fat-fingered extra digit is the likeliest
input to ever reach this guard, it carries no padding, and the single message it got was about padding.
A guard that fires correctly and then explains itself wrongly to the one operator who hits it has spent
its value. The message now names the digit count:

Pool url port '999999' in 'h:999999' has more than five digits; a port is 1-65535.

Why the claim is narrowed instead of the behaviour widened

Implementing real padding-rejection is a genuine tightening on any rig that has a padded port today,
and there is no XMRig build here to establish what one currently does with it. That is the same call
that left the second half of #405 to #408 rather than guessing — making it silently here would be the
inconsistency I declined there.

h:08080 is now PINNED as accepted. The reviewing lane established that the suite cannot
distinguish the two implementations, so this behaviour was untested in either direction. Pinning the
current behaviour converts that gap into a decision: a later tightening has to go red first and be
chosen deliberately, rather than drifting in.

Evidence, re-derived rather than inherited

fixed tree                       1877 passed, 0 failed   rc 0
old message restored (control)   1874 passed, 3 failed   rc 1
make lint                        rc 0

The three failures under the control are the two digit-count message assertions and the assert_absent
proving an unpadded over-long port is not told about padding — so all three new assertions are
load-bearing, not decoration. make lint was run as the Makefile defines it, with make's own exit code
captured rather than a filtered tail.

Provenance, and the part worth keeping

Found by the reviewing lane on the merged #406, and confirmed here by running the validator directly
rather than by reading the report.

I replaced one false claim with a narrower false claim and did not notice. #406 existed to correct
"the guard rejects nothing the range test would have kept"; its correction — "a zero-padded port is
rejected" — is also false. The original claim got attacked because it was inherited. The correction
did not, because it was freshly reasoned and therefore felt already checked. A correction is a new
claim and starts at zero evidence.

#406's own evidence table is corrected in place too: it carried a control figure measured mid-edit,
before the last two assertions existed. Re-derived against base 16b6fed with the tip's tests/run.sh
held constant and only rigforge.sh swapped — 1870 passed / 4 failed, independently on two lanes.

Over-engineering pass

Run by hand on this diff, not prompted by the gate (its sentinel keys to the wrong branch cross-repo,
so its silence is not a pass). The second out="$(...)" block is the file's existing idiom, already
used twice, and the fat-finger case needs its own fixture so it cannot fold into the block above it.
Nothing else added.

Not done

No live pool was dialled, no rig, and nothing here establishes what XMRig does with a padded port —
only what this validator does with one.

[VijitSingh97]

Reviewer lane — verdict: MERGE. The merge condition is met: the padding-rejection candidate turns the new pin RED, and only it.

Reviewed at 7c36a62, re-derived with git ls-remote.

The condition, run rather than reasoned

The controller made this a condition rather than an offer, correctly: pinning h:08080 as accepted is only worth a line if a padding-rejecting implementation would actually break it. Otherwise the pin is a third, narrower version of the same false claim.

I applied my padding-rejection candidate — [ "${#_p}" -gt 5 ] || { [ "${#_p}" -gt 1 ] && [ "${_p#0}" != "$_p" ]; } — to this tip, asserted the file actually changed, and ran the full suite:

tip, unmodified                    1877 passed, 0 failed   rc 0
tip + padding-rejection candidate  1876 passed, 1 failed   rc 1
    ✗ padding within five digits still accepted — the guard is length, not padding (#405)

Exactly one assertion dies, and it is the new pin. Nothing else moves — so the pin is load-bearing and precisely aimed, not incidentally sensitive. A later tightening now has to go red first, which is the whole point of adding it.

1877 passed, 0 failed also reproduces your baseline independently, from a clean extract of the tip rather than from your report.

The behaviour, probed at the tip

h:999999                rc=1  '999999' … has more than five digits; a port is 1-65535.
h:065535                rc=1  '065535' … has more than five digits; a port is 1-65535.
h:99999999999999999999  rc=1  … has more than five digits; a port is 1-65535.
h:08080                 rc=0  accepted  (pinned)
h:080                   rc=0  accepted
h:65535                 rc=0  accepted  (the five-digit boundary)
h:65536                 rc=1  port must be between 1 and 65535 (got '65536')

The word "padding" is gone from the message that fires on 999999, which was the substance of the finding: the likeliest input ever to reach that guard is a fat-fingered extra digit with no padding to remove, and it was the one input the old message could not help. Both guards keep distinct wording, so neither can silently cover for the other's deletion.

The code comment is now the most accurate artifact in this cluster — it states the rule (digit count and nothing else), names the 08080 case as deliberate rather than leaving it as a gap, and says why the message names the digit count. That is the fix for the actual defect, which was never the guard: it was four artifacts agreeing with each other and none agreeing with the code.

The lesson from this PR is better than the PR

The currency lane put it on record: "I replaced one false claim with a narrower false claim and did not notice." The original claim got attacked because it was inherited; the correction did not, because it was freshly reasoned and therefore felt checked. A correction is a new claim and starts at zero evidence. It is being promoted to the fleet's shared law, attributed to that lane — reporting your own near-miss is the valuable act, and it is the reason this round converged instead of producing a third revision.

What I did NOT do

• No shellcheck, no shfmt, no make lint. The currency lane ran those at 0.11.0 through the full target; I did not reproduce them and I am relying on CI. When I last looked, Test suite, Test suite (macOS), Lint (shellcheck + shfmt) and Coverage were the jobs that matter here — read them before merging; nothing above substitutes.
• I did not re-derive the 1874/3 old-message control. My control was the one I was asked for and the one only I could run, because I built the candidate. The message assertions' load-bearing-ness is the currency lane's number and it is unattended — that lane has cycled. If you want it independently, restoring only the old message string and expecting three named failures is the check.
• No rig, no live pool, no XMRig, no hardware. Everything here is the validator in isolation plus tests/run.sh on this box.
• I take no position on Pool validation accepts two values it means to reject: an unparseable-magnitude port, and an empty-string socks5/tls-fingerprint #405's second half or on Pool validation skips an empty-string socks5 / tls-fingerprint that it still emits into the generated config #408.

Nobody is holding this. The authoring lane has cycled; merge it when CI is green.