TautWeekly for Plex v0.19.1

v0.19.1 corrects production-recipient classification and closes several
package lifecycle and Manager diagnostics gaps without changing welcome,
test-email, schedule confirmation, or authentication boundaries.

Production recipient eligibility

Manual and scheduled SendAll now use the same fixed eligibility policy:

• an active, non-deleted Tautulli user with an email address is eligible;
• a checked Manager user box is an explicit exclusion;
• configured legacy email exclusions remain exclusions; and
• Tautulli's legacy do_notify notification-agent flag does not decide whether
  TautWeekly may deliver its own newsletter.

This restores delivery for otherwise eligible users whose upstream
notification-agent flag is disabled. TestEmail and Manual Welcome retain their
existing explicit-recipient semantics.

At the start of every explicitly confirmed manual or scheduled SendAll, the
shared renderer now makes exactly one bounded, authenticated Tautulli
refresh_users_list call and waits for Tautulli to confirm its Plex user-list
update before it fetches the live roster. A user added after the last Manager
discovery is eligible on the next production send unless explicitly excluded;
Repeat this Tautulli lookup remains a Manager-choice refresh and is not
required for delivery. If Tautulli cannot confirm the refresh, the operation
fails before SMTP with the fixed user-roster-refresh-failed category.

The Config user card now says checked means excluded and identifies the
effective exclusion count. Production runs expose only fixed aggregate skip
counts for inactive/deleted users, missing email, explicit user-ID exclusions,
and legacy email exclusions. Names, addresses, URLs, and raw renderer output
are never included in these records.

If every production recipient is skipped, the run now fails with the sanitized
category no-eligible-recipients; it can no longer appear as a successful run
with zero messages accepted by SMTP. Mixed and partial runs retain their actual
accepted, skipped, and failed counts plus the same aggregate skip evidence.

SMTP batch safety

Production messages remain personalized and use exactly one envelope recipient
per SMTP connection. The batch now stops after the first authentication
failure, temporary 4xx provider/service response (including 421), batch-wide
protocol rejection, transport failure, or unknown final-DATA acceptance. A
message is never retried when acceptance is confirmed or ambiguous. A permanent
5xx rejection with an address/mailbox-specific enhanced status at the RCPT
stage is treated as recipient-specific; later
recipient attempts may continue, with the configured spacing applied after the
failed attempt as well as after an accepted message.

Sanitized Manager evidence includes only an allowlisted category and stage,
numeric SMTP response code/class when available, batch-fatal state, and whether
acceptance was not attempted, rejected, or unknown. It excludes provider text,
accounts, hosts, recipients, and credentials. The Manager gives fixed recovery
guidance for authentication, temporary provider-limit, provider rejection,
transport, recipient-only, and ambiguous-acceptance outcomes.

New configurations default to SendDelaySeconds=30 and
TestSendDelaySeconds=10; existing explicit values remain unchanged. Those
intervals reduce connection cadence but cannot override provider account,
quota, reputation, or abuse controls. Avoid Test All or a manual production
send near the scheduled batch. After a provider lock, stop manual checks and
delivery retries, follow the provider's recovery notice, and allow a quiet
period; if access does not return sooner, wait up to 24 hours before escalating
through the provider's normal account-recovery path.

The patch intentionally does not reuse an authenticated SMTP session. Isolated
one-recipient sessions preserve the current privacy boundary, and the
fail-fast circuit breaker avoids reconnect storms without risking a duplicate
retry when DATA acceptance is ambiguous.

First-run and package lifecycle fixes

Numeric Tautulli user IDs can now be written to a brand-new access roster under
Windows PowerShell 5.1. This fixes a first production send that could fail while
creating baseline state before recipient classification. The identical change
ships in the Windows, macOS, NAS/Docker, native Linux, and FreeBSD renderer
payloads.

The supported macOS and generic NAS/Docker restart commands now force-recreate
the TautWeekly app service. Use that command after changing .env; a process
restart alone cannot apply changed container environment values. Vendor-managed
Compose interfaces must perform their equivalent recreate operation while
preserving the mounted private data directory.

Manager access diagnostics

Origin rejections now show fixed browser guidance for malformed origins,
host mismatches, scheme mismatches, and remote HTTP. Native Linux now honors
the documented exact TAUTWEEKLY_MANAGER_ALLOWED_HOSTS DNS allowlist for its
managed service path.

The access boundary is unchanged: the browser origin must still match the
request scheme and allowed Host; protected mutations still require an
authenticated session and CSRF token; remote changes still require HTTPS; and
forwarding headers remain untrusted. The macOS reverse-proxy instructions now
require one exact hostname, original Host preservation, secure cookies, and a
container recreate after environment changes.

Update existing installations

Back up private data, install the v0.19.1 package through the documented update
path, and recreate container packages where instructed. Existing configuration,
credentials, schedules, output, backups, operation history, and welcome state
remain in their existing private locations; no configuration migration is
required.

Validation

The release is covered by a synthetic cross-platform production-send matrix for
all eligible users, a user added after stale Manager discovery, exactly-once
refresh ordering, refresh failure before SMTP, mixed fixed skip reasons, all
do_notify=0 users, all explicitly excluded users, missing email/inactive
users, zero accepted mail, partial SMTP failure, authentication failure after
one attempt, 421 stop-after-one behavior, paced RCPT-only continuation,
ambiguous DATA without retry, successful cadence, first-run numeric access-state
creation, and shared manual/scheduled routing. Manager tests cover strict
structured-result parsing, sanitized operation recovery, visible origin
guidance, native Linux protected DNS-host mutations, and macOS/NAS recreate
commands. Full Go, PowerShell, shell, package, privacy, reproducibility,
installer, desktop, and mobile checks remain part of the release workflow.