harvest: fresh-machine kit deltas + direct-path import defect (F2, F6)

[arcavenai]

Why

Two sessions converged on the same correction from opposite ends. main's
finding-001 + G4 disproved the "proxied-server is the only TLS-capable
client" premise by wire-testing TLS against a deployed instance. Working
from the orchestrator side, I hit the same false premise written into the
Phase-1 attach plan, and building the proxied path is what disproved it
there: 95 proxied-server mode-refusals in cmd/bd against zero for
direct mode, and import/export/remember all working in direct mode
with ids, timestamps, labels and dependency edges intact.

That independent arrival is worth stating and then dropping: main
already has the better-evidenced version (dummy-password discrimination
separating TLS failure from auth failure is a sharper method than mine,
and it correctly isolates the gap to bd init). This PR keeps only what
main does not already say.

What is additive

F2, two kit items from a real second-machine attempt (the failure
that started the whole investigation):

• doctor should assert the effective port, not the configured one.
  bd path-hashes a port when BEADS_DOLT_SERVER_PORT is unset, and its
  auto-start then creates an empty server there, which rejects the
  configured user. So a pointer problem presents as an authentication
  error, and the obvious diagnosis (credentials, keychain) is the wrong
  one. doctor already knows both values, so it is the cheap place to
  catch this.
• A host-specific connection pointer must not be a shared artifact.
  Committing one is precisely how the wrong port reached the second
  machine. Worth stating in the kit rather than leaving to convention.

F6 (i), a defect on the path main just made primary: bd import
miscounts on the direct path. importIssuesCore sets
Created: len(importedIDs) and never sets Unchanged, so existing rows
are reported as created and a converged re-import disagrees with
--dry-run on the same input. Unlike (h), this is on callbook's path:
direct mode is now primary and import is the seeding tool, so a seed
that reports every row as new is a bad signal at exactly the moment an
operator is checking whether the seed took. Reproduced independently on
a second machine; queued for upstream filing. It pairs with aae-orc
finding-081 (import --dry-run never consults the db): the real run and
the dry run compute their counts independently, which is the underlying
weakness.

F6 (h) corrected: our import-leg PR #5181 is not "in flight." I
withdrew it as not fully formed and needing rework, after main was
written.

Docs only, one file. Em-dash, org-token, and shellcheck gates pass
locally; the helm steps of just check need helm, which is not
installed here, and no chart files are touched.

Fuller evidence, including the four other results from the session, is in
aae-orc _kos/findings/finding-088-bd-server-mode-over-proxied-server.md.