Hi Jim,
I'm not sure if this will be helpful, but since I'd still love to see this feature, I'll describe a typical use-case for myself and my collaborators.
We work almost entirely in human data, and have CRAM files indexed against an extended version of the human genome (adding contaminants etc.). The coordinates do match up exactly to GRCh38. I typically view data on a computer which does Not have access to the original extended genome, but don't really care about visualizing read coverage over the extra bits. I've also started programmatically sending read data to IGV by way of hyperlinks, so being prompted for every file seems less than ideal. I expect these are all representative of many other researchers.
I'm also not sure exactly how HTSLib works, but from my understanding of CRAM, the compression it gleans is from saving read coordinates and the difference between the read and reference, and throwing away the read sequence. Therefore in loading reads into IGV, I'm not sure you'd even need to extract out the original read sequence - loading the coordinates should be enough. In short, if the reads match a genome the user has in their IGV, I'm not sure you'd even need the original genome fasta. There may be an engineering bottleneck I'm not aware of though.
So to bring it all together, I think what would work is letting IGV users specify with a preference parameter which local genome to target for a given CRAM genome, as a full file path or using your resource management stuff. If a preference parameter has not been set for a given CRAM genome, then you could prompt. Additionally you could have a preference checkbox to use the environment paths described above.
Thanks again for all your work, love IGV!
Brendan