Why do ed25519 signature verify functions accept 96-byte signatures? Take this piece of code for one example: crypto_sign_ed25519_open() requires that signatures be at least 64 bytes (512 bits) but will accept longer ones, and get_hram() will include extra bytes at the end of the signature in its hashing step if they are present. Yet crypto_sign_ed25519() generates a 64-byte signature.
Is this some kind of legacy thing? Does it have any cryptographic implication?
This is likely an artifact of the API used in the specific piece of code you're using. This piece of code follows the NaCl API, which verifies the input as the concatenation of signature and message (sm) and copies the message out of sm into the message buffer m. The NaCl paper explicitly states on p. 5 et seq. that this is an intentional design choice. The reason why it "will include extra bytes at the end of the signature" is because these seemingly extra bytes are actually the message that was signed.
Thus they're not actually 96-byte signatures, but rather 64+$L$-byte signatures, where $L$ is the length of the signed message in bytes, and 64 is the length of the actual signature.
Note that it is theoretically possible to have 96-byte signatures specifically, by skipping point compression, as noted on the original Ed25519 paper, p. 15, but this isn't the case in the code you're linking as an example.
