feat: [#28] complete Phase 4 - Hetzner Cloud provider implementation

## Phase 4: Hetzner Infrastructure Implementation ✅ COMPLETED

This commit completes Phase 4 of the multi-provider architecture implementation,
adding full Hetzner Cloud support with real-world deployment validation and
comprehensive documentation.

### 🏗️ Core Infrastructure

**Multi-Provider Framework Extension:**
- Extended main Terraform configuration with Hetzner provider support
- Added Hetzner Cloud provider module with standard interface compliance
- Implemented provider-agnostic infrastructure orchestration

**Hetzner Cloud Provider Module:** (/infrastructure/terraform/providers/hetzner/)
- Complete Terraform module with firewall, SSH key, and server resources
- Standard provider interface outputs (vm_ip, vm_name, connection_info)
- Hetzner-specific outputs (server_id, server_type, location, firewall_id)
- Built-in server type validation and memory-to-type mapping
- Cloud-init integration with template processing

### 🔧 Configuration System

**Environment Configuration Templates:**
- production.env.tpl: Production deployment with security hardening
- staging.env.tpl: Cost-optimized staging environment configuration
- Comprehensive variable documentation and examples

**Provider Configuration:**
- hetzner.env.tpl: Template with API token, server types, and datacenter locations
- hetzner.env: Working configuration for testing (with actual token)
- Reference documentation for server types, pricing, and locations

**SSH Key Auto-Detection:**
- Hierarchical SSH key discovery (torrust_rsa.pub → id_rsa.pub → id_ed25519.pub → id_ecdsa.pub)
- Secure SSH key validation in provider interface
- No hardcoded SSH keys - all auto-detected from user's ~/.ssh/

### 🌐 Cloud-init Architecture

**Persistent Volume Strategy:**
- Disabled automatic /dev/vdb mounting for provider compatibility
- Manual volume setup approach for production data persistence
- Comprehensive documentation of data persistence implications
- Support for both persistent and ephemeral deployment models

**Provider Compatibility:**
- Fixed cloud-init template to work across libvirt and Hetzner Cloud
- Conditional disk setup based on provider capabilities
- Enhanced comments explaining architectural decisions

### 📚 Documentation & Guides

**Hetzner Cloud Setup Guide:** (/docs/guides/hetzner-cloud-setup-guide.md)
- Complete deployment walkthrough from account creation to production
- Server type selection guide with pricing and use cases
- Datacenter location reference with geographical recommendations
- Comprehensive troubleshooting section with real-world scenarios
- SSL certificate generation and HTTPS configuration
- Docker Compose usage patterns for persistent volume architecture

**Documentation Enhancements:**
- Updated copilot instructions with Docker Compose remote server guidance
- Enhanced multi-provider architecture plan with Phase 4 completion
- Project word list updated with Hetzner-specific terminology

### 🛠️ Infrastructure Validation

**Real-World Deployment Testing:**
- Successfully deployed on Hetzner Cloud cpx31 server (138.199.166.49)
- Validated HTTPS endpoints with self-signed certificate generation
- Confirmed Docker service orchestration and health checks
- Tested SSH access and cloud-init provisioning

**Manual Testing Configuration:**
- manual-test-config.sh: Helper script for quick Hetzner setup
- Secure password generation for production deployment
- Step-by-step configuration guidance

### 🔒 Security & Production Readiness

**Security Enhancements:**
- Firewall rules for all Torrust Tracker ports (6868/udp, 6969/udp, 7070/tcp, 1212/tcp)
- SSH-only access with key-based authentication
- UFW firewall integration with HTTP/HTTPS support
- Server labeling for resource management

**Production Features:**
- Automatic SSL certificate generation and nginx proxy configuration
- MySQL database backend with proper configuration
- Grafana monitoring dashboard integration
- Comprehensive health check validation

### 🎯 Architectural Decisions

**Persistent Volume Architecture:**
- Manual volume setup validates current Hetzner Cloud limitations
- Volume attachment during provisioning currently broken (Hetzner status page)
- Administrative control over storage configuration and costs
- Clear separation between infrastructure and data persistence

**Provider Interface Compliance:**
- Standard provider interface implemented (vm_ip, vm_name, connection_info)
- Provider-specific extensions for Hetzner Cloud features
- Terraform variable validation for server types and locations
- Time-based wait for server provisioning completion

### 📊 Implementation Status

**✅ Successfully Implemented:**
- Complete Hetzner Cloud infrastructure provisioning
- Multi-provider architecture with pluggable interface
- Real-world deployment validation with HTTPS
- Comprehensive troubleshooting documentation
- Production-ready configuration templates

**✅ Validated Features:**
- HTTPS health check: https://138.199.166.49/health_check → {"status":"Ok"}
- SSH key auto-detection across multiple key types
- Cloud-init provisioning without additional volumes
- Docker service orchestration with proper env-file usage
- Twelve-factor deployment stages (Build/Release/Run)

**📋 Manual Setup (By Design):**
- Persistent volume creation and mounting (for data persistence)
- Domain DNS configuration (for Let's Encrypt SSL)
- Production secret generation (for security)

### 🔗 Related Work

- Builds on Phase 1-3 multi-provider architecture foundation
- Extends libvirt provider patterns to cloud infrastructure
- Maintains backwards compatibility with existing local testing
- Prepares foundation for additional cloud providers (AWS, DigitalOcean, etc.)

This implementation successfully validates the multi-provider architecture
design and provides a production-ready Hetzner Cloud deployment option
for the Torrust Tracker Demo.

## Testing

All CI tests passing:
- ✅ Global syntax validation (yaml, shell, markdown)
- ✅ Project structure and Makefile validation
- ✅ Infrastructure configuration and scripts validation
- ✅ Application configuration and Docker Compose validation
- ✅ Real-world deployment validation on Hetzner Cloud

## Breaking Changes

None. All changes are additive and maintain backwards compatibility
with existing libvirt provider and local testing workflows.

Author: josecelano

.github/copilot-instructions.md

@@ -664,6 +664,40 @@ When executing commands on the remote VM, be aware of limitations with interacti
 
 This ensures that the command is executed and its output is returned to the primary terminal session.
 
+#### Docker Compose on Remote Servers
+
+**CRITICAL**: When working with Docker Compose on deployed servers, the environment file
+is NOT in the standard location. The Torrust Tracker Demo uses a persistent volume
+approach where all configuration files are stored in `/var/lib/torrust` for backup
+and snapshot purposes.
+
+**Always use the `--env-file` parameter** when running Docker Compose commands:
+
+```bash
+# Correct way to run Docker Compose commands on remote server
+ssh torrust@<VM_IP> "cd /home/torrust/github/torrust/torrust-tracker-demo/application && \
+  docker compose --env-file /var/lib/torrust/compose/.env ps"
+
+# Check service status
+ssh torrust@<VM_IP> "cd /home/torrust/github/torrust/torrust-tracker-demo/application && \
+  docker compose --env-file /var/lib/torrust/compose/.env ps"
+
+# View logs
+ssh torrust@<VM_IP> "cd /home/torrust/github/torrust/torrust-tracker-demo/application && \
+  docker compose --env-file /var/lib/torrust/compose/.env logs tracker"
+
+# Restart services
+ssh torrust@<VM_IP> "cd /home/torrust/github/torrust/torrust-tracker-demo/application && \
+  docker compose --env-file /var/lib/torrust/compose/.env restart"
+```
+
+**Why this approach**:
+
+- **Persistent Volume**: All configuration stored in `/var/lib/torrust` for persistence
+- **Backup Strategy**: Snapshot only the volume instead of the entire server
+- **Configuration Management**: Centralized environment variable management
+- **Infrastructure Separation**: Configuration survives server recreation
+
 #### Preferred Working Methodology
 
 **Work in Small Steps:**