Audit log cannot distinguish a legitimate publish from an injected one

Summary

Audit entries record {timestamp, osUsername, clientName, clientVersion, tool, groupUrlname, eventId, result} and nothing about what was actually written. If an agent is induced to publish a defaced event, that log line is byte-identical to a legitimate publish.

Context

The redaction is deliberate and the instinct is right: descriptions, tokens and keys should not be in the log, and docs/live-acceptance.md step 13 checks for exactly that. The gap is that the log now cannot answer the one question it exists to answer.

Suggested fix

Record a SHA-256 of the submitted title and description rather than the values themselves. That stays non-sensitive, keeps the acceptance check passing, and makes it possible to prove after the fact whether what was published matched what the operator approved.

Related, smaller point in the same file

src/audit/audit-logger.ts:41 passes mode: 0o600, which only applies when the file is first created and is effectively a no-op on Windows, currently the only supported platform. The parent directory is created with default permissions at line 40. Either set an appropriate ACL or adjust docs/setup.md so it does not imply the log is access-controlled.

Start with src/audit/audit-logger.ts, especially lines 40-41, and read docs/live-acceptance.md step 13 plus docs/setup.md. Trace the submitted title and description into the audit entry, then verify the log remains non-sensitive while distinguishing different published content; also resolve the file and parent-directory permission behavior documented in the issue.