In general computing, a 'block' is a data storage unit with a fixed total size / storing a fixed number of records. In essence it's just a 'section of' data. If the data exceed the size of a single block, they can be stored in multiple blocks. But the actual space taken up on disk will always be some multiple of the block size, because the FITS file 'allocates space' 2880 bytes at a time. If there's leftover space at the end, it's just left empty. Here's a helpful diagram, courtesy DIY Space Projects:
You can see that the entire header unit is stored over multiple blocks - if one section of the header exceeds the 2880 byte allocation, then another block is added on. (Note that the "END" text there is literal - the header officially ends once it reaches this marker, though it may still be padded out with empty space until it reaches 2880 units.) In your example, where you reach 2880 bytes and then have one extra character to store, that extra character 'costs' 2880 bytes on disk. The system does, in fact, need to allocate two blocks, and the second one will just store the last character (plus the END indicator).
To be honest, this is a fairly low-level detail of the file format that most people don't need to know or interact with. It's a formality, originally used to make file reading and writing more effective on systems that had limitations we no longer regularly deal with. In general, if you are the consumer of a FITS file (or a consumer of a library that makes FITS files), you don't need to know the gritty details of how this works, because it's already abstracted away for you.
