Add an opt-in exact hostname deny-list for every content fetch path

Is your feature request related to a problem? Please describe.

An operator can have a legitimate policy reason to prevent wallabag from contacting a small set of domains: internal policy, known abusive endpoints, or an incompatible external service. Existing post-fetch origin handling cannot enforce this because it runs after a connection has already happened. Network proxies can help, but introduce external infrastructure and may not cover every HTTP client used by the application.

Describe the solution you'd like

Add an opt-in setting such as WALLABAG_FETCH_BLOCKED_HOSTS. It is empty by default and accepts a documented list of canonical hostname rules.

Normalize each hostname once. A rule without a leading dot uses exact matching: example.com blocks only example.com. A rule with a single leading dot explicitly covers a hostname subtree: .example.com blocks example.com and all its descendants, such as www.example.com and deep.api.example.com, without matching unrelated names such as badexample.com.

Do not support wildcards, regular expressions, arbitrary suffix matching, or implicit subdomain matching for exact rules.

Enforce this admission policy before a first request and after every redirect. Apply it consistently to entry fetching, refetching, imports, feed ingestion, email ingestion, background workers, and image downloads. A blocked request should provide a stable user-facing failure while logs retain only diagnostic data appropriate for the deployment's privacy expectations.

Implement the policy at a shared request boundary where possible, with explicit adapters or tests for clients that cannot use that boundary. Document hostname normalization and the behavior for exact rules, leading-dot subtree rules, ports, case, trailing dots, IP literals, and IDNs.

Describe alternatives you've considered

A proxy is deployment-specific and can be bypassed by a client not configured to use it. An origin-rewrite rule cannot prevent the original connection.

Wildcards, regular expressions, and implicit suffix matching are intentionally excluded because their security and user expectations are ambiguous. A leading-dot rule is supported as explicit, documented opt-in syntax for operators who intentionally want to deny both a hostname and its complete subtree.

Additional context

Suggested acceptance criteria:

• the default empty setting preserves current behavior;
• an exact normalized rule blocks only that hostname before any connection;
• an exact rule does not implicitly block subdomains;
• a leading-dot rule blocks both the named hostname and every descendant;
• a leading-dot rule does not block unrelated suffix lookalikes;
• redirects are checked at every hop;
• all content acquisition paths share the same semantics;
• tests cover case normalization, trailing dots, ports, IDNs, IP literals, redirect targets, exact rules, subtree rules, and blocked versus allowed subdomains.

This is an operator-controlled hostname policy, not complete SSRF mitigation.