I iterated this sequence three times before I caught on:
ssh
into Raspberry Pi- Edit
/etc/rc.local
, save changes - Reboot, observe the changes had no effect
cat /etc/rc.local
shows no changes
Then I:
- Edited / saved
- Listed the file to verify the changes
- Rebooted, observe no effect from changes
- Listed the file again: the changes were gone
Huh.

It turns out the card went read-only without warning, so I was displaying the contents of the file cache buffers after the edit, not the data stored on the card. Rebooting started with empty caches, read the previous file contents, and behaved accordingly.
The F3 utilities now live in the Ubuntu repository and no longer require compiling from source. The result:
sudo f3probe --time-ops /dev/sdb F3 probe 6.0 Copyright (C) 2010 Digirati Internet LTDA. This is free software; see the source for copying conditions. WARNING: Probing normally takes from a few seconds to 15 minutes, but it can take longer. Please be patient. Probe finished, recovering blocks... Done Bad news: The device `/dev/sdb' is damaged Device geometry: *Usable* size: 0.00 Byte (0 blocks) Announced size: 7.35 GB (15415296 blocks) Module: 8.00 GB (2^33 Bytes) Approximate cache size: 0.00 Byte (0 blocks), need-reset=no Physical block size: 512.00 Byte (2^9 Bytes) Probe time: 164.4ms Operation: total time / count = avg time Read: 107.1ms / 4098 = 26us Write: 56.6ms / 2049 = 27us Reset: 0us / 0 = 0us
That card has been kicking around for a while and started out as a no-name generic in some random gadget. Of course, those fancy Sony MicroSD cards weren’t shining examples of durability, either.
I’m mildly astonished the streaming player worked perfectly with what amounts to a read-only filesystem, but that’s what caching is all about: there was no need to write the data to “disk”.