[fix] Make reachability re-probe results visible at warn level

[ok]

Why

A StartOS box logging at warn showed nothing about whether the re-probe from #16 ran or what it saw, so a relay stuck firewalled could not be diagnosed from its log.

What changes

• Each scheduled re-probe that fails logs reachability re-probe failed — still firewalled at warn, with the attempt number and the public address the relay currently observes. Only the first 6 attempts (the ramp) are logged, so a port that really is closed does not fill the log.
• A pass logs reachability re-probe passed at warn rather than info: a relay that was red and recovered is exactly what an operator reading a quiet log is looking for.
• The startup FIREWALLED error now carries the observed publicHost / publicPort. An address that is not the expected one means the verdict is about the wrong network path, not about the port.
• onResult receives the attempt number.

What it found

Run on a live box, this is what showed the real cause of a relay going red after every update: the startup probe was aimed at the home IP, not the tunnel's, because StartOS had not re-created the outbound-gateway routing rule for the new container. Once that rule was restored the log showed attempt 11 passing and the relay recovered without a restart — the first real-world proof that the re-probe works.

Testing

• test/unit/reprobe.test.js asserts the attempt numbers passed to onResult.
• npm run lint clean, npm test 409/409.
• Verified on a live StartOS box (see above).