Unfortunately, the information you are asking about and in the form you are asking about is not available in the library (in its direct form).

You can query the (function) name of the decoder used by calling LibRaw:get_decoder_info() and create your own table indexed by the decoder name and containing the properties you need.

In practice, there are very few uncompressed formats now: photographers prefer to save space on flash cards and camera manufacturers follow this wish. Such uncompressed files may still present in archives, but it is hard to find an uncompressed file produced by modern camera (even if camera supports it, photographer will, most likely, switch to compressed format).

If you still want to handle uncompressed formats separately: they can be tiled/striped, so you'll need to add own code that interprets this correctly.

For uncompressed/not tiled data, data starts at libraw_internal_data.unpacker_data.data_offset and
data size is libraw_internal_data.unpacker_data.data_size
These fields are protected (in C++ terms), you may need to subclass LibRaw to access these fields.

Not sure it will be available in the next snapshot, sorry.

Oh and I'm applying this patch to make it compatible with current jxl library:

--- a/dng_sdk_1_7/dng_sdk/source/dng_jxl.cpp
+++ b/dng_sdk_1_7/dng_sdk/source/dng_jxl.cpp
@@ -2283,6 +2283,7 @@ void dng_jxl_decoder::Decode (dng_host &host,
 			// result of JxlDecoderGetColorAsEncodedProfile?
 
 			JxlPixelFormat format = { 3, JXL_TYPE_FLOAT, JXL_NATIVE_ENDIAN, 0 };
+			(void)format;
 
 			#if qDNGValidate
 			if (gVerbose)
@@ -2293,7 +2294,7 @@ void dng_jxl_decoder::Decode (dng_host &host,
 
 			if (JXL_DEC_SUCCESS ==
 				JxlDecoderGetColorAsEncodedProfile (dec,
-													&format,
+													// &format,
 													JXL_COLOR_PROFILE_TARGET_ORIGINAL,
 													&color_encoding))
 				{
@@ -2442,7 +2443,7 @@ void dng_jxl_decoder::Decode (dng_host &host,
 
 				CheckResult (JxlDecoderGetICCProfileSize
 							 (dec,
-							  &format,
+							  //&format,
 							  JXL_COLOR_PROFILE_TARGET_ORIGINAL,
 							  &profile_size),
 							 "JxlDecoderGetICCProfileSize",
@@ -2469,7 +2470,7 @@ void dng_jxl_decoder::Decode (dng_host &host,
 
 				CheckResult (JxlDecoderGetColorAsICCProfile
 							 (dec,
-							  &format,
+							  // &format,
 							  JXL_COLOR_PROFILE_TARGET_ORIGINAL,
 							  profile,
 							  profile_size),
-- 

Could you please check with RawDigger 1.4.10 beta: https://www.rawdigger.com/news/rawdigger-1-4-10-beta

What exact RawDigger version you use for your testing (Windows: Menu - Help - About; Mac - Menu - RawDigger - About)

Thanks, Alex!

This saves on step. I was already fiddling with the imgdata.thumbnail.
I now need to figure out how to decode the JXL data into something my software can use. Looking at the JXL official library at the moment...

Unpacked JPEG XL thumbnail is available via imgdata.thumbnail (and .thumbs_list)

We'll improve dcraw_make_mem_thumb() to handle it too, although this is just another buffer allocation and as-is data copy for JPEG-XL case

You got hit by 'automated maximum adjustment' code implemented in LibRaw's postprocessing many years ago to avoid 'pink clouds' problem: real data range is not present in RAW metadata while real data maximum is lower than format maximum.

To turn the feature off: use
imgdata.params.adjust_maximum_thr = 0;
(corresponding dcraw_emu command line switch: -c 0)

Here are your 0018 file processed via:
dcraw_emu -w -T and dcraw_emu -w -c 0 -T respectively
https://www.dropbox.com/scl/fo/8bgts0j5m5aa8007czqkf/AC8-URS3v42QVYOD_wk...

...didn't get attached. Here it is: https://www.dropbox.com/scl/fi/b1vbngjqyp3837jq0hh8v/LibRaw0.21.3Exposur...

rebuilded, reuploaded, downloaded to another computer: should work now

It is disclosed on this site 1st page: https://www.libraw.org/#updatepolicy

Glad to hear that our advice to start over from scratch and not use development tools that you don't understand what they do helped you.