Docs: setup guide and manual Telegram test #16

Why

A person must be able to set it up without reading the code.

What

• README quick start.
• docs/setup.md: broker with systemd encrypted credentials, the strict known_hosts, a client, a Telegram bot, and account safety (never log in to the approving Telegram account on an agent machine).
• docs/manual-telegram-test.md: the steps for a real-bot test.

Done when

• The setup guide was followed once on a test machine.

• The manual test steps exist.

• The example systemd unit sets LogRateLimitIntervalSec=0. Over its rate limit, journald drops lines without notice, and the audit anchors would be lost. (From the Audit log: hash chain, verify, torn-line recovery #5 review.)

• bws and the standalone bw come from the official releases, owned by root, in directories only root can write to; with an npm bw, the node found through the fixed PATH is owned by root. No bw-data directory next to bw or node. (From the Secret stores: bws and bw #8 review.)

• Login and server setup for a store run with exactly the broker's environment (sudo -u nodkey env -i HOME=<stores>/NAME PATH=<fixed PATH> <program> …); afterwards bw status shows the separate account. No bw lock or bw unlock by hand in a store home. The bw KDF settings let an unlock finish within 30 s. The secret is the password of a login item.

• The example unit sets StateDirectory= (stores directory 0700), UMask=0077, LimitCORE=1, network access to Bitwarden, and no MemoryDenyWriteExecute= when bw (Node.js) is used.

• The broker host keeps a pipe (|) or file core_pattern (the systemd default), because the core limit of 1 does not stop the newer socket (@) form from passing a crash dump with secrets to systemd-coredump. (From the Secret stores: bws and bw #8 review.)