fix: XTC 1-bit thumb BMP polarity inversion (#373)

## Summary

* **What is the goal of this PR?** (e.g., Implements the new feature for
file uploading.)
* **What changes are included?**

- Fix inverted colors in Continue Reading cover image for 1-bit XTC
files

## Additional Context

* Add any other information that might be helpful for the reviewer
(e.g., performance implications, potential risks,
  specific areas to focus on).

- Fix `grayValue = pixelBit ? 0 : 255` → `grayValue = pixelBit ? 255 :
0` in `lib/Xtc/Xtc.cpp`
- The thumb BMP generation had inverted polarity compared to cover BMP
generation
- bit=0 should be black, bit=1 should be white (matching the BMP palette
order)
- Update misleading comment about XTC polarity

---

### AI Usage

While CrossPoint doesn't have restrictions on AI tools in contributing,
please be transparent about their usage as it
helps set the right context for reviewers.

Did you use AI tools to help write this code? _**PARTIALLY**_

lib/Xtc/Xtc.cpp

@@ -203,7 +203,7 @@ bool Xtc::generateCoverBmp() const {
   coverBmp.write(reinterpret_cast<const uint8_t*>(&colorsImportant), 4);
 
   // Color palette (2 colors for 1-bit)
-  // XTC uses inverted polarity: 0 = black, 1 = white
+  // XTC 1-bit polarity: 0 = black, 1 = white (standard BMP palette order)
   // Color 0: Black (text/foreground in XTC)
   uint8_t black[4] = {0x00, 0x00, 0x00, 0x00};
   coverBmp.write(black, 4);
@@ -506,8 +506,8 @@ bool Xtc::generateThumbBmp() const {
             // Bounds check for buffer access
             if (byteIdx < bitmapSize) {
               const uint8_t pixelBit = (pageBuffer[byteIdx] >> bitIdx) & 1;
-              // XTC polarity: 1=black, 0=white
-              grayValue = pixelBit ? 0 : 255;
+              // XTC 1-bit polarity: 0=black, 1=white (same as BMP palette)
+              grayValue = pixelBit ? 255 : 0;
             }
           }