Fix risk area handling to prevent unwanted rate errors and ensure valid methods are still displayed

[robsoned]

Description:

This PR updates the logic responsible for handling delivery methods that contain a delivery_note related to risk areas.

Previously, the module appended an error to the shipping rate result (via append($error) or setError(true)), which prevents Magento from displaying any valid shipping methods, even when they exist. This happened regardless of whether delivery_risk_areas was enabled or disabled, resulting in checkout being blocked unnecessarily.

The new implementation ensures that:

• No error is created when delivery_risk_areas is disabled.
• Only the delivery method containing a risk-related delivery_note is skipped when risk areas are turned off.
• Valid delivery methods continue to be displayed normally.
• Logging occurs only when risk area handling is enabled.
• Error behavior now aligns with configuration expectations.

Checklist:

• Changes are consistent with the project's coding style.
• Link to related issue Shipping methods hidden when delivery_note exists #47

Testing Instructions:

1. With delivery_risk_areas = 0 (disabled):

• Trigger a shipping rate request that includes a delivery_note.
• Confirm no rate error is added.
• Only the method with the delivery_note is skipped.
• All valid shipping methods remain visible.

2. With delivery_risk_areas = 1 (enabled):

• Trigger the same request.
• Confirm the module logs the risk area warning.
• Confirm no rate error is added, and valid methods still display correctly.

[hschmalz-ip]

Revisei a mudança e o fix está correto — remover o setError(true)/append($error) incondicional resolve a causa raiz do #47 (um único delivery_note marcava o RateResult inteiro como erro e o Magento escondia todos os métodos da Intelipost). A nova lógica guiada pela config está coerente:

• delivery_risk_areas = 0 → continue, pula só o método com nota de risco;
• delivery_risk_areas = 1 → loga e deixa o método passar normalmente.

Confirmei também que a remoção de $riskWarning é segura (só era usado nas linhas removidas), que $this->logger existe/está injetado, e que $riskAreaMessage segue definido.

Ponto que quero confirmar antes de aprovar: com essa mudança, o riskareamsg deixa de ser exibido ao cliente — antes ele ia para o errorMessage (visível no checkout, ainda que de forma quebrada) e agora só vai para o log. Isso deixa o campo de config riskareamsg sem efeito user-facing. Está alinhado com o texto do #47 ("optionally log or annotate it"), mas é a única mudança de comportamento não puramente corretiva. A intenção é mesmo não mostrar nenhum aviso ao comprador em área de risco? Se o aviso precisar continuar visível, dá para anexar como RateResult\Method informativo em vez de Error, sem voltar a poluir o resultado com setError(true).

Nits menores (não bloqueiam): há uma linha em branco sobrando dentro do bloco if antes do }; e, com risco ligado, agora cada método com delivery_note gera um warning (antes o guard !$riskWarning limitava a 1 por cotação) — aceitável, só aumenta o volume de log.