State operations and trust facts openly instead of hiding them #261

A single-operator service on shared hosting is a weak answer to "should I put my team's project knowledge here" — but concealing it is worse. Visitors will assume the least favourable version of anything left unsaid. Say it plainly and let the honesty do the work.

A public page (linked from the landing page and the legal footer) that states:

• Who operates the service and that it is a preview run by one person.
• Where data is hosted, in which country, and which processors are involved.
• Backup frequency and what a restore actually recovers; if backups are not yet automated, say that.
• That there is no availability guarantee and no support commitment.
• Security posture in facts rather than adjectives: hashed agent keys with expiry and revocation, scoped permissions, magic links bound to the requesting browser, rotating refresh tokens, TLS, antiforgery on browser POSTs.
• The exits: account export exists today, and the server can be self-hosted once the source is published — the strongest trust argument available, because it makes the operator replaceable.

Also fix the underlying risks, not just the disclosure:

• Verify that backups exist, are restorable, and have been restored at least once in a test.
• Document what happens to user data if the operator stops running the service.
• App_Data/keys on the host holds the data protection key ring; losing it invalidates sessions. Confirm it is backed up separately and securely.

Revisit the wording once the license decision is made, since self-hosting is part of the argument.