Define the use of Mars as Sphere

As described in this RFC, we plan to transition stereo-processing in SOCET SET/GXP to _"1. Initialize projects in SOCET SET using the IAU-recommended sphere for Mars (radius = 3396190 meters)"_ and a couple other updates as described here:
https://astrodiscuss.usgs.gov/t/appl-rfc-use-iau-sphere-for-hirise-dtm-projects-in-socet-set/428

BTW, one additional benefit not described in the RFC, is that we will not need to support the various ocentric/ographic jumps to properly support SOCET. Our current workflow, requires ocentric -> ographic -> ocentric transformations during our full stereo workflow as SOCET only recognizes ographic latitudes. Using a sphere, removes this burden (and data resampling).

So as we test ALE-generated metadata (ISDs) for usgscsm (in GXP), the current ISDs for all Mars (HiRISE and CTX) are defined using the default Mars ellipse which is listed as '"radii": {"semimajor": 3396.19, "semiminor": 3376.2, "unit": "km"}'. I assume the defined ellipse may also be impacting the ISD calculations.

For ISIS's spiceinit, I believe a simple update to Mars within pck00009.tpc should help to define Mars as a sphere. For ALE, I am not sure how to override these Mars defaults. Perhaps updating the same file with the NAIF kernels? But if the kernels are within a common area read-only area, can I update the path to the pck file? Or do I need to copy all the kernels and update the kernel path to grab the updated pck file?

I hope this question makes sense? Now, if there is not an easy way to point to an updated pck file (outside the main generally read-only kernel data area), I guess this could be considered as an enhancement request to allow for a pck/radius override.