Update FMPose3D modelzoo integration - #3221

Note: this PR depends on the bleeding-edge code from the FMPose3D repository. After release, the latest FMPose3D dependency needs to be specified in DeepLabCut before merging.

Summary:
This PR adds a dedicated FMPose3D inference path in the PyTorch modelzoo flow and wires early routing for fmpose3d_* models. It relocates FMPose-specific wrappers/inference helpers to pose_estimation_pytorch/modelzoo/fmpose_3d, standardizes outputs to include explicit 3D artifacts (*_3d.h5 / *_3d.json).

Motivation:
Where the first implementation of FMPose3D in #3208 was rather separated from the rest of the modelzoo pipeline, this PR aims to integrate it better in the existing modelzoo video inference pipeline.

Changes:

1. Revert preliminary implementation in Add fmpose3d functionality #3208:

   • move api wrapper to pose_estimation_pytorch
   • delete recipe notebook on how to use the API

2. Route video inference through video_inference_superanimal:

   • early branching to own video inference pipeline
   • just a thin wrap around FMPose3D, using the superanimal inference format

3. Add brief example usage in the existing superanimal docs

Example usage:

import deeplabcut

video_path = "demo-video.mp4"
result = deeplabcut.video_inference_superanimal(
    videos=[video_path],
    superanimal_name="",  # ignored for fmpose3d models
    model_name="fmpose3d_animals",
    batch_size=8,
    fmpose_return_3d=True,  # (optional: include 3D dataframe in returned payload)
)

Additional considerations / limitations:

• Single-individual 3D limitation: upstream FMPose3D lifting still effectively uses one individual, so multi-animal settings are clamped/warned rather than fully supported.
• Mixed return contract: enabling fmpose_return_3d changes payload structure, which adds API complexity for callers.
• Inconsistent parameter intuition: the entire 2D modelzoo convention currently follows the intuition that superanimal_name -> means 'dataset family' and model_name -> means 'model architecture'. For FMPose3D the 'dataset family' is different and therefore ignored.
• Inseparability: the core principle of FMPose3D is lifting 2D keypoints to 3D, however to simplify the integration, FMPose3D is treated as a single model that directly computes video -> 2D -> 3D and the 2D step is now made inseparable. Therefore, users that want to use the 3D lifting on their own 2D keypoints should use the FMPose3D api, rather than this modelzoo inference function.
• No Video adaptation / Transfer learning: while the other 2D modelzoo models can be finetuned using video adaptation or further trained using pretrained weight initialization this is not the case for the FMPose3D model. If people want to finetune the backbone 2D estimator, they should work with a standard 2D superanimal model and use the FMPose3D api for lifting their keypoints, which is fairly straightforward.
• Redundant outputs: consistent with the 2D superanimal pattern, both JSON and HDF 3D artifacts are written, which increases storage and maintenance overhead. This might need to be reconsidered in the future.
• Format bridge complexity: FMPose outputs are converted into DLC-style 3D DataFrames, consistent with the 3D pipelines in DeepLabCut. While this works fine if formatting conventions are kept the same, a more robust (validated) data format would be useful.