zedagent: fix docs inaccuracies from review

[eriknordmark]

Description

As I've said, the output needs to be reviewed. I looked over zedagent.md and zedagent-internals.md before they were merged but I didn't review every sentence. I did that today (actually using annotated pdf copies of the markdown files which claude figured out how to parse and extract the comments), and I came up with 17 issues (one "please check" and 16 "this looks incorrect") against zedagent.md and a few against zedagent-internals.md.

While the incorrect things aren't random hallucinations, they do show a lack of attention to detail. I don't know if it is useful to add "Please double check your work" to the prompt.

---

See the individual commit messages for the full list; highlights:

• zedagent.md: bootstrap-config path made explicit with a fourth
  fallback to types.DefaultConfigItemValueMap; the controller-cert
  fetch by zedclient is called out at the onboarding gate; saved
  config moved above bootstrap in the source-hierarchy table;
  ConfigItemValueMap layering corrected (LPS does not override);
  config-fetch jitter corrected to [0.3, 1.0] x ConfigInterval;
  deferred queue described as holding objects keyed by identity.
• zedagent-internals.md: Publications table now shows concrete
  pubsub-key literals; Attestation FSM section frames the
  controller↔TPM flow and lists the three EVE-API ZAttestReq types;
  Maintenance Mode table is corrected (apiMaintenanceMode is a
  dedicated protobuf field; the GlobalConfig knob is maintenance.mode,
  controller/LOC only; localMaintenanceMode is one of six
  MaintenanceModeReason enum values).

How to test and validate this PR

Render the two markdown files (GitHub preview or markdown-to-pdf)
and review the affected sections. Each correction is grounded in
grep-verified code references cited inline (file:line).

Changelog notes

No user-facing changes (documentation only).

PR Backports

• 16.0-stable: No, docs-only fix.
• 14.5-stable: No, docs-only fix.
• 13.4-stable: No, docs-only fix.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device (N/A — docs-only)
• I've tested my PR on arm64 device (N/A — docs-only)
• I've written the test verification instructions

[milan-zededa]

While the incorrect things aren't random hallucinations, they do show a lack of attention to detail. I don't know if it is useful to add "Please double check your work" to the prompt.

I don’t think throwing more AI at the hallucination problem is the right solution. Every PR, including AI-generated ones, should still be reviewed carefully, first by the person signing off on it, and then by the rest of the team (or at least a smaller review group).

Erik, I noticed you’ve opened a large number of PRs this month already. Are you realistically able to review all of them thoroughly, or are the AI agents effectively opening and submitting these PRs on your behalf? At the end of the day, the author of the PR is still responsible for its contents, regardless of whether parts of it were generated by AI.

We also should not merge AI-generated code or text unchecked, including documentation and tests. Incorrect or low-quality generated content eventually becomes training material, examples, and references for future systems, which only compounds the hallucination and quality problems over time.