refactor: remove obsolete resource download and installer endpoints

- Deleted the `POST /resources/get/{dataFolder?}` and `GET /resources/get-installer` endpoints as part of the architectural shift towards simplified resource management.
- Removed associated methods and configurations, including `ResourcesService.GetEncryptedResource`, `ResourcesService.GetInstaller`, and related properties in `ResourcesConfig`.
- Cleaned up environment variables and configuration files to reflect the removal of installer-related settings.
- Eliminated the `GetResourceRequest` DTO and its validator, along with the `WrongResourceName` error code.
- Updated documentation to clarify the changes in resource handling and the retirement of per-user file encryption.

Co-authored-by: Cursor <cursoragent@cursor.com>

_docs/02_document/tests/blackbox-tests.md

@@ -184,51 +184,17 @@
 
 ---
 
-### FT-P-09: Download Encrypted Resource
+### FT-P-09: Download Encrypted Resource — OBSOLETE (cycle 2, 2026-05-14)
 
-**Summary**: Authenticated user downloads an encrypted resource file.
-**Traces to**: AC-14, AC-18
-**Category**: Resource Distribution
+The `POST /resources/get/{dataFolder?}` endpoint, the `Security.GetApiEncryptionKey` / `EncryptTo` helpers, the `ResourcesService.GetEncryptedResource` method, the `GetResourceRequest` DTO, and the e2e tests `Encrypted_download_returns_octet_stream_and_non_empty_body` (in `ResourceTests.cs`) and `Per_user_encryption_produces_distinct_ciphertext_for_same_file` (in `SecurityTests.cs`) were all removed. The endpoint now returns 404 — verified by FT-N-16 below.
 
-**Preconditions**:
-- User authenticated, hardware bound, resource file uploaded
-
-**Input data**: `{"password":"validpwd1","hardware":"test-hw-001","fileName":"test.txt"}`
-
-**Steps**:
-
-| Step | Consumer Action | Expected System Response |
-|------|----------------|------------------------|
-| 1 | POST /resources/get with credentials | HTTP 200, Content-Type: application/octet-stream, non-empty body |
-
-**Expected outcome**: HTTP 200 with encrypted binary content
-**Max execution time**: 10s
+ID retained for traceability stability; do not regenerate the spec body until a full `/test-spec` rerun.
 
 ---
 
-### FT-P-10: Encryption Round-Trip Verification
+### FT-P-10: Encryption Round-Trip Verification — OBSOLETE (cycle 2, 2026-05-14)
 
-**Summary**: Downloaded encrypted resource decrypts to original file content.
-**Traces to**: AC-15, AC-19
-**Category**: Resource Distribution
-
-**Preconditions**:
-- Known file uploaded, user credentials known
-
-**Input data**: Original file content, user email, password, hardware hash
-
-**Steps**:
-
-| Step | Consumer Action | Expected System Response |
-|------|----------------|------------------------|
-| 1 | Upload known file | HTTP 200 |
-| 2 | Download encrypted file via API | HTTP 200, encrypted bytes |
-| 3 | Derive AES key from email + password + hwHash | Key bytes |
-| 4 | Decrypt downloaded content with derived key | Decrypted bytes |
-| 5 | Compare decrypted bytes with original | Byte-level equality |
-
-**Expected outcome**: Decrypted content matches original file exactly
-**Max execution time**: 10s
+Same removal as FT-P-09. Additionally `Security.DecryptTo` and the e2e test `Encryption_round_trip_decrypt_matches_original_bytes` (in `ResourceTests.cs`) are gone. ID retained for traceability stability.
 
 ---
 
@@ -487,12 +453,38 @@ The following legacy entries describe behaviour removed by AZ-197 (admin-side ha
 - FT-P-04 (First Hardware Check Stores Fingerprint) — superseded; the `POST /resources/check` endpoint and the hardware-store side-effect were removed.
 - FT-P-05 (Subsequent Hardware Check Matches) — superseded; same endpoint removed.
 - FT-N-06 (Hardware Mismatch) — superseded; the `HardwareIdMismatch` / error code 40 path no longer exists in `ExceptionEnum`.
-- FT-P-09 / FT-P-10 wire shape — the `hardware` field on `POST /resources/get/{dataFolder}` is no longer required; the encryption key is now derived from `email + password` only. The tests still pass without the field; do not regenerate spec bodies until a full `/test-spec` rerun.
+- FT-P-09 / FT-P-10 — fully obsolete after the cycle-2 cleanup; the endpoint, support code, and corresponding e2e tests are gone (see the FT-P-09 / FT-P-10 stubs above and FT-N-16 below).
 
 See `_docs/03_implementation/batch_06_report.md` for the full AZ-197 implementation rationale and the wire-compat policy decision (drop entirely).
 
 ---
 
+### Cycle-2 Cleanup (2026-05-14) — Obsolete Resource Endpoints Removed
+
+#### FT-N-16: Removed Resource Endpoints Return 404
+
+**Summary**: After the cycle-2 cleanup, the three obsolete resource endpoints are no longer routed and return 404.
+**Traces to**: Cycle-2 AC-1, Cycle-2 AC-2, Cycle-2 AC-3
+**Category**: Negative — Removed Endpoints
+
+**Preconditions**:
+- Caller authenticated as any user (404 must precede any auth check, since the route is gone)
+
+**Steps**:
+
+| Step | Consumer Action | Expected System Response |
+|------|----------------|------------------------|
+| 1 | `POST /resources/get` (with or without body) | HTTP 404 |
+| 2 | `POST /resources/get/somefolder` | HTTP 404 |
+| 3 | `GET /resources/get-installer` | HTTP 404 |
+| 4 | `GET /resources/get-installer/stage` | HTTP 404 |
+
+**Expected outcome**: each request returns HTTP 404 (not 401, not 405); no `Security.GetApiEncryptionKey` / `EncryptTo` invocation observable in logs.
+
+**Notes**: this is a parallel to FT-N-15 (which covers the AZ-197 endpoint removals). Together they enumerate every route that has been retired in cycles 1 and 2.
+
+---
+
 ### Detection Classes CRUD (AZ-513)
 
 #### FT-P-14: POST /classes Creates Detection Class