fix: allocate CRPS accumulator on the input device

[shaun0927]

Description

calc_quantile_crps and calc_quantile_crps_sum (in
pypots/nn/functional/error.py) initialize their running accumulator with
CRPS = torch.tensor(0.0), which always lives on CPU. The subsequent
CRPS += q_loss / denominator then tries to mix that CPU scalar with tensors
that inherit the input device (CUDA, MPS, …), and raises:

RuntimeError: Expected all tensors to be on the same device, but got CRPS
is on cpu, different from other tensors on cuda:0.

This makes both metrics unusable whenever predictions / targets are on
anything other than CPU — a surprising limitation for a PyTorch-first
toolkit, and out of step with sibling metrics like calc_mae which stay
device-agnostic.

Changes

• pypots/nn/functional/error.py: allocate the CRPS accumulator on
  predictions.device in both calc_quantile_crps and
  calc_quantile_crps_sum. Two one-line changes, no behavioral change for
  CPU callers (the accumulator's device matches what it already was).

Testing

CPU path is untouched, so existing call sites keep their previous behavior.
The device-matching path was verified manually:

import torch
from pypots.nn.functional import calc_quantile_crps

device = "cuda" if torch.cuda.is_available() else "mps"
P = torch.randn(2, 3, 5, device=device)
T = torch.randn(2, 3, 5, device=device)
M = torch.ones(2, 3, 5, device=device)
calc_quantile_crps(P, T, M)   # no longer raises

The fix is scoped to pypots/nn/functional/error.py only and does not touch
the existing _check_inputs signature, so there is no interaction with the
in-flight #821.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud