feat: complete issue #6 - implement feature toggle integration in routes

- Add conditional route registration based on feature toggles
- AuthEnabled now controls authentication/user management endpoints
- ClusteringEnabled controls member and Merkle tree endpoints
- RevisionHistoryEnabled controls history endpoints
- Feature toggles for RateLimitingEnabled and TamperLoggingEnabled were already implemented

This completes issue #6 allowing flexible deployment scenarios by disabling
unnecessary features and their associated endpoints.

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>

issues/3.md

@@ -0,0 +1,71 @@
+# Issue #3: Implement Autogenerated Root Account for Initial Setup
+
+**Status:** Open  
+**Author:** MrKalzu  
+**Created:** 2025-09-12 22:17:12 +03:00  
+**Repository:** https://git.rauhala.info/ryyst/kalzu-value-store/issues/3
+
+## Problem Statement
+
+The KVS server lacks a mechanism to create an initial administrative user when starting with an empty database and no seed nodes. This makes it impossible to interact with authentication-protected endpoints during initial setup.
+
+## Current Challenge
+
+- Empty database + no seed nodes = no way to authenticate
+- No existing users means no way to create API tokens
+- Authentication-protected endpoints become inaccessible
+- Manual database seeding required for initial setup
+
+## Proposed Solution
+
+### 1. Detection Logic
+- Detect empty database condition
+- Verify no seed nodes are configured
+- Only trigger on initial startup with empty state
+
+### 2. Root Account Generation
+Create a default "root" user with:
+- **Server-generated UUID**
+- **Hashed nickname** (e.g., "root")
+- **Assigned to default "admin" group**
+- **Full administrative privileges**
+
+### 3. API Token Creation
+- Generate API token with administrative scopes
+- Include all necessary permissions for initial setup
+- Set reasonable expiration time
+
+### 4. Secure Token Distribution
+- **Securely log the token to console** (one-time display)
+- **Persist user and token in BadgerDB**
+- **Clear token from memory after logging**
+
+## Implementation Details
+
+### Relevant Code Sections
+- `NewServer` function - Add initialization logic
+- `User`, `Group`, `APIToken` structs - Use existing data structures
+- Hashing and storage key functions - Leverage existing auth system
+
+### Proposed Changes (from MrKalzu's comment)
+- **Added `HasUsers() (bool, error)`** to `auth/auth.go`
+- **Added "Initial root account setup for empty DB with no seeds"** to `server/server.go`
+- **Diff file attached** with implementation details
+
+## Security Considerations
+
+- Token should be displayed only once during startup
+- Token should have reasonable expiration
+- Root account should be clearly identified in logs
+- Consider forcing password change on first use (future enhancement)
+
+## Benefits
+
+- Enables zero-configuration initial setup
+- Provides secure bootstrap process
+- Eliminates manual database seeding
+- Supports automated deployment scenarios
+
+## Dependencies
+
+This issue blocks **Issue #4** (securing administrative endpoints), as it provides the mechanism for initial administrative access.