feat(notification): enable production publisher

Preserve production broker definitions and allow bounded SMTP delivery.

Ref: IT-1508

docker/kubernetes/shared-notification/README.md

@@ -6,8 +6,9 @@ Ingress, NodePort or unauthenticated administration. Application administration,
 RabbitMQ management and the sandbox inbox are available through explicit local
 `kubectl port-forward` sessions over SSH.
 
-The initial channel is `Invemory.Staging.Sandbox`, template `TestEmail`, exact language
-`en`. SMTP egress permits only Mailpit:1025. Mailpit has no relay configuration.
+The initial sandbox channel is `Invemory.Staging.Sandbox`, template `TestEmail`, exact
+language `en`. Its SMTP egress uses Mailpit:1025, which has no relay configuration.
+The production add-on also permits the Worker to reach external SMTP on TCP 587.
 Only its temporary inbox is ephemeral. Channels, templates, SMTP settings and usage
 counters are persisted in PostgreSQL; durable broker queues, messages, users and
 permissions are retained on the RabbitMQ volume. Never put real SMTP credentials
@@ -37,10 +38,59 @@ default-exchange publication. Resource ACLs constrain exchange/queue names, not
 routing key of a publish operation: access to the default exchange permits routing
 to other existing queues within the same vhost. This MVP shared-queue design therefore
 does not provide security isolation between message ServiceNames or routing keys.
-No production publisher or SMTP egress is configured.
+The production publisher credential, result queue, network policies and SMTP egress
+are provisioned separately below.
 Additional environments need separately reviewed routing, users, permissions, exact
 templates, provider settings and egress before they can join the shared service.
 
+## Invemory production publisher credential
+
+The additive `activate-production-publisher.py` provisions the dedicated
+`invemory_production` user in `/notification`, durable result queue
+`invemory.production.notification-results`, and the Notification Worker permissions
+for that result queue. It preserves the staging user and queue. Run it on mini-pc-2
+as `devops` from its reviewed copy; repeated runs verify the existing password and
+ACLs. The generated password is retained only in
+`/home/devops/shared-notification-private/invemory-production-rabbitmq-password.txt`
+with mode `0600`. It is never printed by the provisioning script.
+
+On mini-pc-2, the owner can display the password in their own terminal with:
+
+```sh
+sudo -u devops cat /home/devops/shared-notification-private/invemory-production-rabbitmq-password.txt
+```
+
+Use the `invemory_production` user, that password, broker
+`rabbitmq.shared-notification.svc.cluster.local:5672`, vhost `/notification`, send
+queue `notification.send-email`, result queue
+`invemory.production.notification-results`, and the existing technical service name
+`StoreMate-Prod` in the Invemory production notification settings. The visible sender
+and `TestEmail` text still contain legacy branding; IT-1510 tracks that copy change.
+
+### Live activation — 2026-10-03
+
+`production-network.yaml` adds only production API/Outbox egress and RabbitMQ ingress
+on TCP 5672, plus shared Worker egress to public SMTP on TCP 587 (private and cluster
+address ranges excluded). The existing sandbox Mailpit allowance stays intact. The
+file passed Kubernetes server dry-run and was applied on mini-pc-2. The API result
+consumer and both Workers are running at one replica; RabbitMQ has one consumer on
+`notification.send-email` and one on
+`invemory.production.notification-results`. Two owned production test messages were
+published, accepted by the Gmail SMTP channel, acknowledged as delivery successes in
+Invemory Outbox, and confirmed in the recipient's Gmail conversation. Today's channel
+usage increased by two. Both queues ended with zero ready and unacknowledged messages.
+
+The activation helper also persists the production user, queue and expanded Worker ACL
+in the `rabbit-definitions` Secret. The private password and matching RabbitMQ hash
+are saved with mode `0600`; updated `notification.py` reproduces that Secret during
+bootstrap without rotating passwords. The reviewed source is installed at
+`/home/devops/notification-package/notification.py`, with its pre-activation copy
+retained beside it. A broker restart should therefore reload production access;
+verify the two consumers and an owned delivery afterward. The SMTP password remains
+outside the repository. Apply `production-network.yaml` separately when reconciling
+network policies. Do not use the initial sandbox-only render as a complete production
+delivery configuration.
+
 Web/API administration has no built-in authentication in this source revision. Its
 Service stays ClusterIP and default-deny ingress; access through SSH/port-forward is
 restricted to operators. The worker exposes no health HTTP endpoint. Pod rollout is