Fix #1071: Rename forecast_sample_multivariate class to match constructor

[seabbs-bot]

Summary

• Fixes naming inconsistency where class forecast_sample_multivariate did not match constructor as_forecast_multivariate_sample() (word order mismatch)
• This caused transform_forecasts(append = TRUE) to fail on multivariate sample forecasts because it dynamically constructed as_forecast_sample_multivariate (wrong name) from the class
• The mismatch was introduced in commit f017891 when the constructor was renamed per review feedback but the class name was not updated

Changes

• Class renamed from forecast_sample_multivariate to forecast_multivariate_sample
• Backwards compatibility: old class name retained in class vector during deprecation so inherits(x, "forecast_sample_multivariate") still works
• Deprecated: is_forecast_sample_multivariate() in favour of is_forecast_multivariate_sample()
• S3 method aliases: deprecated aliases for score, get_metrics, and assert_forecast methods retained
• get_forecast_type(): now takes first matching forecast_* class to handle dual-class deprecation period
• joint_across made optional: when data already has .mv_group_id (needed for transform_forecasts object reconstruction)
• Example data regenerated with new class structure

Test plan

• All 56 multivariate sample + transform tests pass
• Full test suite passes (687/688, 1 pre-existing unrelated snapshot failure)
• transform_forecasts(append = TRUE) now works on multivariate sample forecasts
• Deprecated is_forecast_sample_multivariate() emits warning and still returns correct result
• Both old and new class names present in class vector for backwards compat

Closes #1071

This was opened by a bot. Please ping @seabbs for any questions.

[seabbs-bot]

Note on deprecation wrappers: Since multivariate scoring hasn't been included in a CRAN release yet (it was merged after v2.1.2), no external users have the old forecast_sample_multivariate class name. The deprecation wrappers (is_forecast_sample_multivariate(), the deprecated S3 method aliases, and the old class in the class vector) are therefore not strictly necessary for backwards compatibility right now.

Options:

1. Keep them as-is for safety during the development cycle, then remove before the next CRAN release
2. Remove them now since no one outside of development is using the old names

I'd suggest option 1 (keep for now, remove before CRAN) as the safest approach since it avoids breaking any in-progress work that might reference the old names (e.g. hubEvals development), but we should clean them up before going to CRAN to avoid shipping deprecated code that was never public.

This was opened by a bot. Please ping @seabbs for any questions.

[seabbs]

This looks good to me. As noted I think we probably don't need to push to CRAN with the mismatched naming but can drop the depreciations instead (having some warning of this does seem like a good idea for those living on the bleeding edge).

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.85%. Comparing base (fe9c9f0) to head (2243f77).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1072      +/-   ##
==========================================
+ Coverage   97.83%   97.85%   +0.02%     
==========================================
  Files          35       35              
  Lines        1845     1865      +20     
==========================================
+ Hits         1805     1825      +20     
  Misses         40       40              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[seabbs]

Some linting issues to clean up

[nikosbosse]

Thanks @seabbs