fix: config path advisory ignores XDG file on interactive root (#81) (#83)

Port-53 and TLS-data-dir advisories told users to create
~/.config/numa/numa.toml, but config_dir() routed root to
/var/lib/numa/ and load_config never consulted the XDG path, so
the file the user created was silently ignored.

New suggested_config_path() helper prefers $HOME/.config/numa/
when HOME is set (and isn't "/" or empty), with config_dir() as
lazy fallback. Used by both advisories and by load_config as an
additional candidate, so the advised path is the path numa
actually reads. Runtime state (services.json, TLS CA) stays in
FHS — config_dir()/data_dir() are intentionally unchanged to
keep continuity with the installed daemon.

End-to-end replication + regression check in
tests/docker/issue-81.sh: four scenarios (replication and
existing-install, each against main and fix), all matching
expectations.

src/system_dns.rs

@@ -91,7 +91,7 @@ pub fn try_port53_advisory(bind_addr: &str, err: &std::io::Error) -> Option<Stri
          sudo numa install       (on Windows, run as Administrator)
 
     2. Run on a non-privileged port for testing.
-       Create ~/.config/numa/numa.toml with:
+       Create {} with:
 
          [server]
          bind_addr = \"127.0.0.1:5354\"
@@ -100,7 +100,8 @@ pub fn try_port53_advisory(bind_addr: &str, err: &std::io::Error) -> Option<Stri
        Then run:  numa
        Test with: dig @127.0.0.1 -p 5354 example.com
 
-"
+",
+        crate::suggested_config_path().display()
     ))
 }