I think this is due to the allowed semantics of []byte("a"). It must return a slice of length 1, but the capacity might be larger. A [0:10] slice of the result may pass.
The choice of capacity may depend on other optimization decisions, like inlining.

If you replace []byte("a") with []byte("a")[:1:1] you get a panic as expected.

Ah, you are correct. It appears that in the inlined version the capacity is always 32 (until your input string is larger) and in the not inlined version it's 8. Inlining decisions indeed affect the capacity of the byte slices. And it appears the increment of the capacity depends on inlining decisions as well.

This holds true even when converted from user input. So it's possible that a user could pass in a string and the failure of the program given various inputs could depend on whether or not the code was inlined. Would the recommended way to handle this be to slice the input and enforce the capacity to be equal to the length of the input to ensure you cannot read past the end of the buffer? (something like bytes = bytes[:len(bytes):len(bytes)]?)

Or should this be handled entirely by logic to ensure the read position isn't > len(bytes)? (I thought that's what I was doing but apparently that logic wasn't working right and the tests were not catching it because of the inlining)

(something like bytes = bytes[:len(bytes):len(bytes)]?)

That's a good backstop. Your logic of course should make this not matter. It's only when the logic is wrong that this behavior is noticeable.
Proper unit tests should catch this kind of thing, as you're likely getting a wrong result if you're reading and using data beyond the end of the original string.

The other option is don't covert to []byte. Do everything you need using string.