First of all, the *.tic file format allows for chunk sizes smaller than the memory associated with them. This is a very simple compression method for carts, in case you have zero-filled bytes left at the end of the memory region. The remaining bytes that are not stored in the file are therefore zero when the chunk is loaded.

But this isn't fully true for the 48-byte palette memory though. When TIC-80 saves a cart, it applies this compression method to the palette chunk in the file (along with the sprites, map, sound, etc. chunks). The loading process is the slightly different part for palettes.

Instead of filling the remaining palette memory with zeroes (or black colors/intensities in this case), it instead uses the DB16 palette's byte values at offsets n...47 (where n is both the size of the palette chunk in the cartridge file, and the offset of the first palette memory byte to not be present in the chunk). This may ruin a game's palette.

Repro Steps:

1. Create a new cart with new command.
2. Paste this palette string into the palette editor (saved chunk is 8 bytes, 40 bytes are filled):

00000000000000ff00000000000000000000000000000000000000000000000000000000000000000000000000000000

3. Save the cart with whatever filename.
4. Re-load the cart you just saved.

Expected Result: The palette should be two blacks, followed by a green and thirteen more blacks.
Preserved Result: The palette instead becomes two blacks, followed by a mint green, and then DB16 colors 3...15.

A workaround is to make color 15 have the darkest level of blue, i.e. RGB #xxxx01.