Bounds-check macroblock/motion/audio indices to fix four OOB accesses (#73)

[nakata-app]

This fixes the four memory-safety bugs reported in #73, all reachable from crafted MPEG-1 input via plm_decode_video() / plm_decode_audio(). Three targeted bounds checks, no behavior change on valid streams.

1. plm_video_decode_macroblock, negative mb_row/mb_col (Bug A read at :3532, Bug D write at :3514/:3519)

The existing guard checks only the upper bound. When macroblock_address is driven negative, mb_row/mb_col become negative, both >= checks pass, and the derived di index goes negative. In the non-intra path that is an OOB read (d[di]); in the intra path PLM_BLOCK_SET does an OOB write (heap corruption, 16 bytes before the frame plane). Adding the lower-bound check closes both.

2. plm_video_process_macroblock, half-pel interpolation past plane end (Bug B read at :3372)

The old max_address guard reserves room for the block_size x block_size block but not for the half-pel neighbors the interpolation cases read (s[si + dw + 1] at the bottom-right). The new guard checks the actual maximum index touched: the block span for the write side (di), plus the interpolation neighbor (+ dw + 1, gated on odd_h/odd_v) for the read side (si). This rejects only reads that would leave the plane; valid motion compensation stays in-bounds.

3. plm_audio_decode_header, bitrate_index == -1 (Bug C, global read at :4076)

bitrate_index = read(4) - 1 yields -1 for the free-format nibble 0. The guard only rejects > 13, so -1 slips through to PLM_AUDIO_BIT_RATE[-1]. Reject the negative case too.

Verification

• clang + AddressSanitizer, harness decoding all video+audio frames.
• Before: all four reproducers from Two heap out-of-bounds reads in the MPEG-1 video decoder (decode_block :3532, process_macroblock :3372) #73 crash under ASan (3 heap-buffer-overflow, 1 global-buffer-overflow).
• After: all four exit cleanly, no ASan report.
• No regression: a valid 320x240 MPEG-1 clip (75 frames + audio) decodes to byte-identical output before and after the patch (FNV-1a hash e2dba4d8a37b5192 on both builds).