HANDOFF + MyMistakes: officerFriendly clock is the PS5 DNS root cause (no RTC exists); record the reply marker verbatim

Off-repo diagnosis (Pi 400, no RTC hardware, healthy crystal at -7.39 ppm):
the box's clock sat ~43 h behind and systemd-timesyncd's first contact after
the Oct 12 restart was 42.9 h later, so Pi-hole ran as a DNSSEC validator with
a wrong clock -> 1.69M+0.84M dnssec=3 (BOGUS) rows on 10-11/10-12 hitting the
PSN endpoints = the PS5's DNS errors. KSK-rollover theory retracted (both root
anchors present; root DNSKEY still returns ad). Pending creator decision:
tighten timesyncd polling and/or add a DS3231 RTC.

MyMistakes: the reply marker string (recovered verbatim, with the search
recipe), and the no-RTC/no-cron/timesyncd facts so the premise is not
re-derived a third time.

HANDOFF.md

@@ -13,6 +13,8 @@
 - **This session produced NO code, NO build, NO test run.** It specified the creator's **vv
   (vertical 9:16) webcam feature** end to end; implementation has not started. The locked rules are
   below — they are the deliverable, and they must land in `TASKS.md` when work is queued.
+  The session's later half moved **off-repo** to the officerFriendly/Pi-hole/PS5 "DNS errors" diagnosis —
+  findings and the pending creator decision are in `Open (operational)` below.
 
 ## vv webcam feature — locked rules (creator, 2026-10-17)
 | mode | shape | size | position |
@@ -109,9 +111,32 @@
 - Recordings land in `C:\Users\gramp\Downloads\recordings\` (`ty-<date>-<time>-<ms>-<seq>.mp4`; a
   duplicate name gets a `-2` suffix — the log's path and the file on disk can differ that way).
 - **Conversation history (how to recover what was actually said):**
-  `~/.local/share/opencode/opencode.db`, table **`session_message`** (`type='user'`, text in
-  `data.text`). The `part` table holds only assistant-authored text — searching it for a creator
-  message returns nothing. Recipe + command in `MyMistakes.md`.
+  `~/.local/share/opencode/opencode.db`, table **`session_message`** — creator turns are `type='user'`
+  with the text in `data.text`; my turns are `type='assistant'` with **reasoning AND the rendered reply
+  concatenated into `content[0].text`** (so my own reasoning quotes the creator's phrases — a `part` or
+  `data.text` hit may be my echo, not a real message). The **reply marker's verbatim string is recorded
+  in `MyMistakes.md`** (it was lost once and cost a session to re-derive).
 - LAN credentials: `CREDENTIALS.md` (gitignored). Google Cloud OAuth project number `198374416003`,
   owned by `llamachile.shop@gmail.com` — verify at
   `https://console.cloud.google.com/apis/credentials?project=198374416003`.
+
+## Open (operational) — officerFriendly / PS5 "DNS errors" (2026-10-17, off-repo work)
+- **Root cause found: a ~43 h-wrong system clock on officerFriendly × `dnssec = true`.** The box is a
+  **Pi 400 with no RTC hardware at all** (no `/dev/rtc*`, `hwclock` cannot open one, no `i2c-rtc`
+  overlay) and a **healthy oscillator** (`adjtimex` freq = −7.39 ppm = −0.64 s/day), so there is no
+  "dead RTC battery" — time comes from `fake-hwclock`'s saved file + `systemd-timesyncd`. The journal
+  shows the clock stepping forward **+54 min, +7 h, then +42.9 h** (last step Oct 14 13:56:44, the first
+  successful time-server contact after the Oct 12 19:01:43 restart). A validating resolver with a wrong
+  clock returns BOGUS, and `pihole-FTL.db` shows exactly that: **1,688,396 `dnssec=3` rows on 10-11 and
+  839,276 on 10-12 vs ≤23 every other day**, hitting `ps5.np.playstation.net` and the other PSN
+  endpoints = the PS5's "DNS errors". The KSK-rollover theory is **retracted**: both root anchors
+  (`20326` + `38696`) were already in place, and `dig @127.0.0.1 . DNSKEY` still returns `ad`.
+- **Pending creator decision (do not apply unilaterally):** tighten
+  `/etc/systemd/timesyncd.conf.d/lan.conf` (currently IP-literal NTP servers = Cloudflare + Google, but
+  stock poll settings) to `PollIntervalMinSec=16` / `PollIntervalMaxSec=64` / `ConnectionRetrySec=8` /
+  `SaveIntervalSec=30`, and/or give the Pi a DS3231 RTC on i2c (`i2c-tools` is already installed).
+- **LAN DNS routing vs creator intent:** DHCP still hands out `dhcp_dns1_x = 192.168.50.26` +
+  `dhcp_dns2_x = 192.168.50.1` (clients query Pi-hole **directly** — 37 distinct LAN nodes in 24 h, 41
+  including the router), whereas the creator wants everything to point at `.1` with BBR forwarding to
+  Pi-hole (`wan_dns = 192.168.50.26` already works: `.1` made 3811 queries). Also `dnssec = true` on
+  Pi-hole duplicates dnscrypt-proxy's `require_dnssec = true`. Both are offered-for-veto, not yet done.