[canvas branch] Splash + status bar never render — initialise() and DisplayController::update() are commented out

## Summary

On `test/canvas-mono-plus-pins-strings` the display **splash screen and status bar never render**, because both entry points are commented out:

1. **`src/components/display/controller.cpp:339`** — the call that draws them:
```cpp
// hw->initialise(Ws._configV2.aio_user);
```
`DisplayHardware::initialise()` is `showSplash(); drawStatusBar(aio_user);`, so commenting out the call removes *both*. On `add/lilygo-t-dongle-c5` (and earlier branches) this is live at `controller.cpp:221`.

2. **`src/components/display/controller.cpp:758-780`** — the whole body of `DisplayController::update()` (the periodic status-bar icon refresh) is commented out, with TODOs explaining the motivation:
```cpp
// TODO: TRICOLOR and QUADCOLOR (not sure about grayscale) displays take a
// LONG time to refresh
// TODO: maybe kill this functionality if they are actively using Marquee,
// and refresh the status bar along with the marquee?
```

This reads as deliberate WIP rather than an accident — the reasoning for EPDs is sound (a tricolor refresh is ~15 s, and doing that once a minute while Marquee is driving the panel is clearly wrong). Opening this so it isn't lost before the branch merges, because the blanket comment-out also disables it for **SPI TFTs, where a status-bar redraw is sub-millisecond**.

## Impact

On a LilyGO T-Dongle C5 (ST7735 160x80) on this branch: no splash, no status bar, ever. Verified on hardware — the pre-merge build logs `[display] Updating status bar...` after a display Add, this branch never does.

## Suggested shape of a fix

There's now a natural gate for it: `DisplayProperties.status_bar`. Until today that field was decoded and then read by nothing; I've plumbed it through `beginSpiTft()` → `dispDrvBase::setStatusBar()` so `writeMessage()` honours it (PR to follow / commit `5e899a2f` on `tyeth-ai-assisted:feature/t-dongle-c5-canvas-marquee`).

Options, roughly in order of preference:

1. **Re-enable both, gated on the display's `status_bar` flag**, and additionally skip the periodic `update()` for EPD classes (or while a Marquee canvas is active) — keeps the fast TFT path working without paying the EPD refresh cost.
2. Split `initialise()` so the **splash** is independent of the **status bar** — right now they're coupled, and gating the pair on `status_bar` would also suppress the splash, which isn't intended.
3. If the intent is that Marquee owns the panel entirely, redraw the status bar *as part of* the canvas composition (the second TODO's suggestion) rather than on a timer.

Happy to send a PR for (1)+(2) if you tell me which way you want it — I didn't want to unilaterally re-enable something that was switched off on purpose.

Found while getting the marquee canvas path working end-to-end on the T-Dongle C5's ST7735.

@tyeth

Read src/components/display/controller.cpp around lines 339 and 758-780, then inspect DisplayHardware::initialise() and the DisplayProperties.status_bar path through beginSpiTft() and dispDrvBase::setStatusBar(). Decide how splash rendering, status-bar gating, EPD refresh costs, and Marquee interaction should be separated. Done means the ST7735 splash and status bar render on the canvas branch without causing inappropriate periodic refreshes on EPD or Marquee displays.

Written by the indexing model from the issue text.