feat: add forbidden layers configuration for deletion (MAPCO-11281)

[almog8k]

Question	Answer
Bug fix	✖
New feature	✔
Breaking change	✖
Deprecations	✖
Documentation	✖
Tests added	✔
Chore	✖

Related issues: MAPCO-11281

Further information:

Adds a safety mechanism that protects specific layers from being deleted.

Configuration

A forbidden-layers list is configurable at Helm values level under env.deleteLayer.forbiddenLayers, exposed to the service as the FORBIDDEN_LAYERS_FOR_DELETION env var (JSON array) and read from deleteLayer.forbiddenLayers. Defaults to an empty list, so behavior is unchanged unless explicitly configured.

env:
  deleteLayer:
    # layers that are protected from deletion, in the format of <productId>-<productType>
    forbiddenLayers:
      - 'VIVID_IHUD-Orthophoto'

Behavior

deleteLayer now runs validateLayerIsNotForbiddenForDeletion as its first validation — before the unpublished check and the parallel-jobs check — so a protected layer is rejected as early as possible and no delete job is created. Layers are matched by their map serving name (getMapServingLayerName(productId, productType)), meaning both productId and productType must match an entry; a partial match on either one alone does not block deletion.

On a match the request fails with 403 Forbidden (ForbiddenError) — the request does not conflict with any state, it is simply not permitted:

Layer: VIVID_IHUD-Orthophoto, is configured as a forbidden layer for deletion and therefore cannot be deleted

The 403 response is documented on the delete endpoint in the OpenAPI spec, and ForbiddenError is mapped to StatusCodes.FORBIDDEN in the deleteLayer controller handler.

Tests

• Integration: DELETE on a configured forbidden layer returns 403 and no job is created on job-manager.
• Unit: forbidden layer throws ForbiddenError; productId-only match still deletes; productType-only match still deletes.

Full suite passes (tsc --noEmit + 159 unit + 216 integration = 375 tests) and eslint . is clean.