stalwart: record that the public-side ACME path is not fully verified

The private direction of the mode switch is exercised end to end. The
public one has only ever run against a throwaway .test domain, where Let's
Encrypt rejects the contact address before the provider is created — so
everything past that call is reasoned rather than observed.

The plan shape IS confirmed up to that point: contact is a set, matchOn is
the directory URL, and a domain cannot reference automatic certificate
management without an acmeProviderId. What is unproven is the link holding
once the provider actually exists.

Saying so in the file beats leaving it in a chat log nobody reads.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

containers/stalwart/tools/stalwart_set_mode.sh

@@ -70,6 +70,14 @@ appStalwartSetMode() {
             # server that was private has never had one — so create it here
             # rather than failing with "ACME provider not found".
             #
+            # NOT FULLY VERIFIED. The private direction below is exercised end to
+            # end, but this one has only ever been run against a throwaway .test
+            # domain, where Let's Encrypt refuses the contact address before the
+            # provider is created — so the AcmeProvider -> Domain link past that
+            # point is reasoned, not observed. The plan shape is confirmed up to
+            # the LE call (contact is a set, matchOn is the directory URL, an
+            # acmeProviderId is required). Worth one run on a real domain.
+            #
             # Two things about this are worth knowing. Creating the provider
             # REGISTERS AN ACCOUNT with Let's Encrypt there and then, so it is a
             # real outbound action, not a local setting. And the challenge type