Release v4.5.1 -- output_resolution numeric type fix

[jhkennedy]

Test INSAR_ISCE_TEST jobs:

• ❌ with no output_resolution specified:
  https://hyp3-enterprise-test.asf.alaska.edu/jobs?user_id=jhkennedy&name=Los-Angeles-0_64_HRRR_1121_part-deux
  • these failed due to the job timeout being hit, but did start running succfully, which they did not in v4.5.0, so really, ✔️ for this PR
• ✔️ with output_resolution specified as an int:
  https://hyp3-enterprise-test.asf.alaska.edu/jobs/2b718b83-7684-449b-9db2-a6c9d6dc7e41
• ✔️ and I get the expected rejection with a float output_resolution:
  

[github-actions]

Developer checklist

• Indicated the level of changes to this package by affixing one of these labels:

  • major -- Major changes to the API that may break current workflows
  • minor -- Minor changes to the API that do not break current workflows
  • patch -- Patches and bugfixes for the current version that do not break current workflows
  • bumpless -- Changes to documentation, CI/CD pipelines, etc. that don't affect the software's version

• (If applicable) Updated the dependencies and indicated any downstream changes that are required

• Added/updated documentation for these changes

• Added/updated tests for these changes

• If the step function code has changed, have you drained the job queue before merging?

  • For example, if the interface for a Lambda function has changed to expect different input,
    then currently running jobs (which use the old step function definition) will call the new
    function with the old input. So we must drain the job queue before deployment, so that the new
    function is only called by the new step function definition.

Reviewer checklist

• Have all dependencies been updated?
• Is the level of changes labeled appropriately?
• Are all the changes described appropriately in CHANGELOG.md?
• Has the documentation been adequately updated?
• Are the tests adequate?

[jhkennedy]

The no output_resolution specified batch of jobs all failed by hitting the timeout, getting 17%-ish through in 6 hours.

Notably, we are running on c6id instances in the JPL deployment and have ++omp-num-threads 4 set in the job spec, but in enterprise-test we are running on r6id instances which have 1/2 the CPUs available for the same memory reservation.

I suspect the timeout was caused either all or in part by CPU contention with multiple jobs running, but it could also just be due to new options/layers enabled.

I think we should just ship this so we can test the new options @ JPL and we really should set up test deployments for our science envs.