Remove two disclosures, and record Nox as the answer to 006

Found by a full scan before making the repository public, which is the
moment the public rule stops being aspirational.

A module name identified a specific laptop model — hardware inventory,
which is operational detail about one installation rather than a lesson
that travels. Generalised.

ADR 0028 named a forge username in a repository path, which the public
rule forbids, and the sentence had also gone stale: the repository it
described was subsequently verified empty of anything unique and removed.
Rewritten to state what happened without the username. Removing a
disclosure from a record is the same class as fixing a path — the rule
that permits it outranks the one that forbids editing.

Issue 006 gains its proposed direction: Nox works from within this
repository rather than these documents being synced into the knowledge
base. Better on three counts — no copy, so no drift; no fourth knowledge
system, which was the original objection; always current.

But it changes the promise, and the issue says so. ADR 0019 promised these
documents would surface BESIDE everything else in a symptom search. An
agent that must be asked is reachable, not surfacing, and the two differ
in precisely the case the operational memory exists for — someone
debugging an error with no reason to suspect HQ knows anything about it.
The question narrows to whether a symptom search finds this content
without the searcher already suspecting it.

01-RESEARCH/003-service-supervision/analysis.md

@@ -176,8 +176,8 @@ init — without the recursion.
 
 Worth noting what is *not* in this table: the dozens of `systemctl` call sites that
 configure the **host OS's own** units — NetworkManager, resolved, oomd, zram, docker.service,
-fail2ban, sshd, zfs, across `modules/asusd`, `g14-power`, `wireguard`, `sshd`, `zfs` and
-others. Those are not HAL supervising itself; they are HAL configuring an Arch box. They
+fail2ban, sshd, zfs, across the vendor-firmware and power modules, `wireguard`, `sshd`, `zfs`
+and others. Those are not HAL supervising itself; they are HAL configuring an Arch box. They
 are out of scope for every option above and do not go away under any of them.
 
 ---