Torch-native PDF pipeline + origin finder improvements

[ehrhardtkm]

What problem this PR addresses

Follow-on to #177 (the polar transform + PDF pipeline that merged into nanobeam). This PR brings that work onto dev and lands the changes I've made since.

Conceptually unchanged — same Polar4dstem datastructure, same PairDistributionFunction shape, same overall workflow (origin → polar → PDF). The public API should be the same, except for a few minor changes.

Changes since #177:

• Fully torch-native, dual-backend pipeline. The whole pipeline accepts numpy or torch input on the existing Dataset, device is inferred from the input, and there are no GPU↔CPU round-trips inside the pipeline. numpy vs tensor input give identical results.

• Background fitting. Rewritten with an analytic Jacobian that is noticeably faster than the previous implementation. Added a batched fit_bg_batched path for full-dataset use, which the downstream PDF widget (PR3) needs to recompute backgrounds interactively. Also includes some small fixes I picked up while running this on real data.

• Origin finding. The existing finder's hardcoded margin requirement caused it to error out on smaller detectors, so I made it the margin dynamic and added a 2D-quadratic subpixel refinement (renamed to find_origin_angular_grid). I also added a secondary option, find_origin_angular_descent, a margin-free, COM-anchored descent finder. It's slower but I've found it slightly more reliable on noisier data. Both are dispatched from Polar4dstem.from_data(origin_method="grid"|"descent").

• Tests in tests/diffraction/test_polar.py are parametrized over both origin finders and add coverage for the new code paths.

Out of scope (follow-on PRs to shortly follow):

• Elliptical-distortion fit + reciprocal-pixel calibration → PR2, stacks on this branch.
• ShowPDF widget vendor → PR3.

What should the reviewer(s) do

Merge after review. Reviewing commit-by-commit is likely easier than the unified diff — each commit is a single conceptual change.

• This PR introduces a public-facing change (e.g., figures, CLI input/output, API).
  • For functional and algorithmic changes, tests are written or updated.
  • Documentation (e.g., tutorials, examples, README) has been updated.
  • A tracking issue or plan to update documentation exists.
• This PR affects internal functionality only (no user-facing change).

[bobleesj]

@ehrhardtkm before I review, it seems like being merged to upstream/dev instead of upstream/nanobeam. Has upstream/nanobeam containing pdf code merged to upstream/dev?

[bobleesj]

Another question I had was from the PR comment was - what's approx speed/improvement given various sizes? Mostly likely it will be either 512x512x192x192 or 256x256x192x192 to be practical, just ballpark numbers.

Ref:

• drift: speed up align_affine() to handle 2048×2048, 4096x4096 pairs in seconds #206
• drift: speed up align_nonrigid() to handle 2048×2048, 4096x4096 pairs in seconds #208