fix: return nbytes instead of *buf_size in nbit and scaleoffset no-op paths

Per the HDF5 filter API, nbytes is the count of valid data bytes in the
buffer, while *buf_size is the allocated buffer capacity. These two values
were historically always equal on the read path, so either worked in
practice. The pre-sizing change (which sets buf_alloc = chunk_size before
the filter pipeline) makes *buf_size > nbytes for compressed reads,
exposing the latent bug.

In H5Znbit.c: the no-compress pass-through (cd_values[1] == 1) was
returning *buf_size, causing the next filter (e.g. fletcher32) to treat
the full pre-sized buffer as valid data and compute a checksum over
uninitialised bytes.

In H5Zscaleoffset.c: the no-process path had the same pattern. No current
test exercises this path through a multi-filter pipeline where the size
mismatch would be observable, but the fix is correct by the same API
reasoning.

Author: brtnfld

src/H5Znbit.c

@@ -939,7 +939,7 @@ H5Z__filter_nbit(unsigned flags, size_t cd_nelmts, const unsigned cd_values[], s
      * cd_values[1] stores the flag if true indicating no need to compress
      */
     if (cd_values[1])
-        HGOTO_DONE(*buf_size);
+        HGOTO_DONE(nbytes);
 
     /* copy a filter parameter to d_nelmts */
     d_nelmts = cd_values[2];

src/H5Zscaleoffset.c

@@ -1187,7 +1187,7 @@ H5Z__filter_scaleoffset(unsigned flags, size_t cd_nelmts, const unsigned cd_valu
 
         /* no need to process data */
         if (scale_factor == (int)(cd_values[H5Z_SCALEOFFSET_PARM_SIZE] * 8)) {
-            ret_value = *buf_size;
+            ret_value = nbytes;
             goto done;
         }
         minbits = (uint32_t)scale_factor;