Optional password protection for status pages

**Is your feature request related to a problem? Please describe.**
At the moment, all status pages in Peekaping are public and can be accessed by anyone who knows the URL. While this works well for transparency, in many cases I would prefer to restrict access to certain audiences (e.g. only internal teams, customers with credentials, or while testing before going public). This lack of access control can be problematic when sensitive infrastructure details should not be visible to the general public.

**Describe the solution you'd like**
I would like to have an **optional password protection** (or simple authentication) for status pages. Ideally:
- A toggle in the admin UI to enable/disable protection.
- A configurable password that needs to be entered before the page is displayed.
- A simple login prompt (HTTP Basic Auth or lightweight form).
- Secure storage of the password (e.g. hashed).
- Backward compatibility: status pages remain public unless protection is explicitly enabled.

**Describe alternatives you've considered**
- Hosting Peekaping behind a reverse proxy with authentication rules (e.g. Nginx basic auth). This works, but is less convenient, requires extra infrastructure, and cannot be configured per status page inside Peekaping.
- Restricting access at the network/firewall level, but this removes the flexibility to share the page selectively with clients.
- Waiting for a potential larger role-based access system, but a simple password protection would already cover the most common needs with much less complexity.

**Additional context**
- Use case: sharing a status page only with paying customers or internal staff before making it public.
- This feature would align with future plans for user accounts or groups, but could be implemented as a lightweight intermediate solution.
- It would increase the adoption of Peekaping in environments with compliance or security requirements.

Analise a lógica de renderização da página de status e os componentes da UI de administração. O recurso requer a adição de um alternador de autenticação, armazenamento de senhas (provavelmente com hash no banco de dados) e um prompt de login (HTTP Basic Auth ou um formulário). Verifique os padrões existentes de usuário/autenticação na base de código. Um recém-chegado precisaria entender a estrutura do projeto para lidar com rotas, middleware e configuração.

Escrita pelo modelo de indexação a partir do texto da issue.