docs: add GitBook public documentation

[TerrifiedBug]

Summary

• Add complete public documentation site (docs/public/) for GitBook Git Sync
• 22 pages across 4 sections: Getting Started, User Guide, Operations, Reference
• ~4,300 lines of documentation adapted from internal docs and source code
• Add docs badge and link to README

Documentation Structure

• Getting Started (4 pages): quick-start, deploy server, deploy agents, first pipeline walkthrough
• User Guide (8 pages): dashboard, pipelines, pipeline editor, VRL snippets, environments, fleet, alerts, templates
• Operations (6 pages): architecture, configuration, authentication, backup/restore, security, upgrading
• Reference (4 pages): API reference, agent reference, database schema, pipeline YAML

GitBook Integration

• .gitbook.yaml config points GitBook at docs/public/
• SUMMARY.md defines sidebar navigation
• GitBook-flavored markdown (tabs, hints, steppers) for rich formatting
• Screenshots included from existing docs/screenshots/
• Auto-exposes MCP server, llms.txt, and llms-full.txt when published

Test plan

• Verify GitBook syncs and renders all pages correctly
• Check all screenshot references resolve
• Verify SUMMARY.md navigation matches published sidebar
• Test MCP server endpoint responds
• Verify llms.txt and llms-full.txt are generated

[greptile-apps]

Greptile Summary

This PR adds a complete 22-page public documentation site (docs/public/) for GitBook Git Sync, covering Getting Started, User Guide, Operations, and Reference sections, along with a docs badge in README.md. After verification against the actual codebase, one factual inconsistency was found and kept.

Issues found:

• Backup code storage method incomplete in security.md — The encryption-at-rest table lists 2FA backup codes as stored via "SHA-256 hash", but the actual implementation (src/auth.ts) stores backup codes as an array of SHA-256 hashes that is then encrypted with AES-256-GCM before database storage. This should be documented as AES-256-GCM for consistency with reference/database.md which correctly indicates they are in the AES-encrypted section.

Verified as accurate:

• /api/agent/config is correctly documented as GET in both agent.md and the response examples (with VF_SECRET_ prefix shown correctly on line 145).
• Reference documentation for API, agent, and pipeline YAML are consistent with actual server implementation.
• Authentication and configuration documentation are accurate and well-organized.

Confidence Score: 4/5

• Safe to merge — one minor factual inconsistency corrected in security.md encryption table; no code changes or runtime risk.
• Documentation-only PR with no code changes, so zero runtime regression risk. One verified factual inconsistency found in the encryption-at-rest table (backup codes storage method). The correction is straightforward and aligns the documentation with the actual codebase implementation. All other major documentation sections (agent reference, architecture, database schema, API) are accurate and consistent with the server code.
• docs/public/operations/security.md (encryption table for 2FA backup codes)

_{Last reviewed commit: 88784cb}

[greptile-apps]

The encryption-at-rest table shows 2FA backup codes as stored via "SHA-256 hash", but this is incomplete. In the codebase (src/auth.ts and src/server/services/totp.ts), backup codes are hashed with SHA-256, but the resulting array of hashes is then encrypted with AES-256-GCM before database storage. This should match the description in reference/database.md (lines 233–238), which correctly indicates User.totpBackupCodes is in the AES-encrypted section.

For clarity and consistency with the database schema documentation, the storage algorithm should be updated to reflect the actual encryption method:

Suggested change

	| 2FA backup codes | SHA-256 hash | -- |
	| 2FA backup codes | AES-256-GCM | SHA-256 hash of `NEXTAUTH_SECRET` |

(The backup codes themselves are hashed for comparison, but the encrypted storage method is what's relevant in this table.)

Prompt To Fix With AI

This is a comment left during a code review.
Path: docs/public/operations/security.md
Line: 64

Comment:
The encryption-at-rest table shows 2FA backup codes as stored via "SHA-256 hash", but this is incomplete. In the codebase (src/auth.ts and src/server/services/totp.ts), backup codes are hashed with SHA-256, but the resulting array of hashes is then encrypted with AES-256-GCM before database storage. This should match the description in `reference/database.md` (lines 233–238), which correctly indicates `User.totpBackupCodes` is in the AES-encrypted section.

For clarity and consistency with the database schema documentation, the storage algorithm should be updated to reflect the actual encryption method:

```suggestion
| 2FA backup codes | AES-256-GCM | SHA-256 hash of `NEXTAUTH_SECRET` |
```

(The backup codes themselves are hashed for comparison, but the encrypted storage method is what's relevant in this table.)

How can I resolve this? If you propose a fix, please make it concise.