const vs readonly vs static readonly in C#: which should I use for configuration values?

A const is a compile-time constant. The compiler substitutes its value at every place it is used, including in other assemblies that reference yours, so the application's compiled code contains the literal 9600 and no reference to your field. Replacing the library DLL cannot change that; the application has to be recompiled.

A static readonly field is a real field, initialised at run time when the type is first used. Other assemblies read it from your DLL at run time, so a new value is picked up. The rule that follows: use public const only for values that will never change, such as mathematical constants or numbers fixed by a protocol, and static readonly or a property for anything that might differ between versions.

They also differ in what they can hold. const is limited to the built-in numeric types, bool, char, string, enums and null references, and the initialiser must be a constant expression. It is implicitly static; writing static const is an error.

readonly works with any type and any expression: static readonly TimeSpan Timeout = TimeSpan.FromSeconds(5); and static readonly byte[] Header = { 0xAA, 0x55 }; are fine, and neither could be a const. On the other hand, only const values may be used where the language demands a constant: case labels, attribute arguments, default parameter values and other const initialisers.

An instance readonly field, without static, holds one value per object. It can be assigned only in its declaration or in a constructor and is fixed afterwards: private readonly int _address; set from a constructor argument. It documents that the object does not change after construction, and the compiler enforces it.

One caveat: readonly freezes the field, not the object it refers to. With static readonly byte[] Header = { 0xAA, 0x55 }; nobody can assign a new array to Header, but anyone can write Header[0] = 0;. Expose IReadOnlyList<byte>, ReadOnlySpan<byte> or an ImmutableArray<byte> if the contents must be protected as well.

Performance is rarely a reason to choose. A const is folded at compile time, and the JIT can treat a static readonly field of a primitive type as a constant once the type has been initialised, so in optimised code the difference usually disappears. Decide on meaning instead.

For values that change per deployment rather than per release, neither is right: read them from a configuration file, environment variable or command line at start-up. Ask the question about your 115200: if the device's bootloader fixes the rate, a constant is fine; if users attach different devices, it is configuration. Finally, optional parameter defaults behave like const: with void Open(int baud = 9600) the 9600 is compiled into every caller, so changing the default also requires recompiling the callers.