Gradients of the existing bilateral filter layers (normal and PHL)

[faebstn96]

Describe the bug
The backward operations of the existing bilateral filter layers (normal and PHL) do not calculate the correct derivative of the filter prediction with respect to the filter input. Currently, they use the exact same filter forward function as the backward operation, which is not the correct derivative as shown in here. This issue is related to #1840 and may be partly fixed by pull-request #5757.

As discussed with @wyli we should think about how to treat the existing bilateral filter implementations (normal and PHL). I believe that their forward operations are fast and valid operators which can be valuable for users. However, their provided gradient is not correct I think. The normal bilateral filter implementation could be replaced by the #5757 version in the medium term as their forward operations are almost identical.

To Reproduce
Steps to reproduce the behavior:

1. Install BUILD_MONAI=1 pip install --no-build-isolation git+https://github.com/Project-MONAI/MONAI#egg=monai
2. Run the gradcheck

import torch
from monai.networks.layers import BilateralFilter


tensor_in = (torch.randn(2, 1, 10, 10, 10, dtype=torch.double, requires_grad=True))
filter = BilateralFilter.apply
gradcheck(filter, (tensor_in, 1.1, 0.5), eps=1e-6, atol=1e-5)

Expected behavior
Gradcheck passes.

Current behavior
Gradcheck fails as visible in the screenshot.

[medhavee-upadhyaya]

I am interested in taking this on if the maintainers still want the legacy BilateralFilter gradient corrected. I found no open PR addressing #5772. My first step would be to reproduce the CPU gradcheck failure on current dev for both the exact and PHL-backed paths, then compare the legacy operator semantics with TrainableBilateralFilterFunction, which now has a dedicated analytical backward implementation. Before changing the public behavior, could a maintainer confirm whether the preferred direction is (a) implementing a correct backward for the legacy operator, (b) routing/deprecating it in favor of the trainable implementation where compatible, or (c) explicitly disabling its incorrect backward? I can prepare focused CPU regression coverage first and keep CUDA parity as a separately validated part of the design.

[medhavee-upadhyaya]

Current-state verification: I built monai._C from dev at c1240a2d on macOS arm64 with Python 3.11.14 and PyTorch 2.13.0, then ran torch.autograd.gradcheck on a small double-precision CPU tensor. Both fast_approx=False (exact bilateral path) and fast_approx=True (PHL-backed approximation) still fail with a Jacobian mismatch. So #5772 remains reproducible on current dev; it is not only a historical failure. I will hold production/API changes until the preferred compatibility direction is confirmed.