Fix clock offset extraction dropping positive values

2026-07-01T09:35:27Z

ntpq's "rv 0 offset" prefixes non-negative offsets with an explicit "+" (e.g. "offset=+0.030208"), which wasn't in the sed capture class ([-0-9.]). Since the capture group is starred, the regex still "matched" with an empty capture instead of failing outright, silently producing "no response" for every positive/zero offset while negative ones (which do use "-", already in the class) worked fine. Confirmed against the real box: earlier renders with negative drift worked, then it started showing "no response" once the drift crossed zero. Co-Authored-By: Claude Sonnet 5

Add ntpd/clock-sync check and a pre-commit hook for exec bits

2026-07-01T07:36:55Z

checks/ntpd.sh reports whether ntpd is running and whether the clock's offset is within tolerance (ok <50ms, warn <200ms, down beyond that or if ntpq doesn't respond) - clock drift is a silent failure that otherwise only surfaces later as TLS handshake failures or misleading cross-jail log timestamps. Also add .githooks/pre-commit + core.hooksPath, since this checkout is on Windows where core.fileMode is false (the filesystem doesn't reliably preserve the executable bit) - without it, a plain `git add` on a new check script silently stages it as non-executable, and render.sh skips non-executable files with no visible error. Co-Authored-By: Claude Sonnet 5

console.git/statuspage/checks/ntpd.sh, branch master

Fix clock offset extraction dropping positive values

Add ntpd/clock-sync check and a pre-commit hook for exec bits