iter26 α-26: populate decode_params.short_term_ref_pic_set_size from VAAPI

VAPictureParameterBufferHEVC exposes st_rps_bits — the number of bits
the inline short_term_ref_pic_set syntax element takes in the slice
header. rkvdec's DPB resolution for P/B frames uses this to skip the
RPS data correctly; with size=0 it skips wrong bytes and reads wrong
references → frame 2+ visual divergence.

iter25 evidence: libva HEVC frame 1 byte-identical to kdirect, but
frame 2 diverges at the decode_params bytes 4-5 (libva 0x00 0x00,
kdirect 0x0a 0x00 = 10).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

src/h265.c

@@ -312,9 +312,19 @@ static void h265_fill_decode_params(struct request_data *driver_data,
 	decode_params->num_poc_st_curr_before = n_st_before;
 	decode_params->num_poc_st_curr_after = n_st_after;
 	decode_params->num_poc_lt_curr = n_lt;
-	/* short_term_ref_pic_set_size, long_term_ref_pic_set_size,
-	 * num_delta_pocs_of_ref_rps_idx left zero (VAAPI doesn't expose;
-	 * matches FFmpeg's behavior for non-bitstream-driven population). */
+	/*
+	 * iter26 α-26: VAAPI DOES expose short_term_ref_pic_set bit-count
+	 * via picture->st_rps_bits. Without populating this, rkvdec's
+	 * DPB reference resolution for P/B frames uses the wrong slice-
+	 * header skip and reads the wrong reference; frame 1 (IDR) decodes
+	 * correctly but frames 2+ diverge (iter25 evidence: cmp differs at
+	 * byte 1382401 = frame 2 boundary, kdirect bytes 4-5 = 0x0a 0x00,
+	 * libva = 0x00 0x00).
+	 *
+	 * long_term_ref_pic_set_size and num_delta_pocs_of_ref_rps_idx still
+	 * left zero (VAAPI doesn't expose either).
+	 */
+	decode_params->short_term_ref_pic_set_size = picture->st_rps_bits;
 
 	/*
 	 * iter11 α-14: IRAP/IDR/NO_OUTPUT_OF_PRIOR flags. VAAPI doesn't