docs: make the account colour the card's accent, not a chip

The plan left the account chip unspecified, because where it sits on a card was
never decided and inventing a place would have been a guess. The user's answer
replaces it rather than placing it: a coloured bar down the card's left edge,
the reply spines inheriting that colour, and matching swatches in the account
dropdown.

It is a net simplification. The chip ate a third of line 2 on every card to
repeat a name the user already knows, which is the table-of-records texture item
53 is about; the bar says the same thing in a few pixels and leaves line 2 to
the subject.

Three details that are easy to get wrong and are specified rather than left to
the implementer:

  - The raw account colour is never drawn as a line. It is chosen to be a
    chip's FILL, with text drawn on top in whatever stays legible against it. A
    thin line on the pane's own background has a different job: followable down
    a long expansion without competing with the senders beside it. The accent
    blends toward QPalette::Base by the same 0.35 weight threadLineColour()
    already uses, keeping the hue and dropping the shout. The dropdown swatch
    does use the raw colour, being a filled patch rather than a line.
  - A reply resolves its THREAD's colour by walking to the root.
    AccountColourRole is empty on a message row, so a spine reading its own
    index would fall back to the neutral line under an accented root and break
    the continuous edge the design is built on.
  - Reply cards carry no bar of their own. Two vertical lines a few pixels
    apart in one gutter is what option B looked like, and the spine already
    carries the accent.

colourFor() never failing is kept deliberately: an account with no colour= key
gets a stable colour derived from its tag name, so adding an account and
forgetting to colour it degrades to something usable rather than to nothing.

kAccentWidth ships at 3px as a starting value. Whether five accounts are
tellable apart at that width, on this user's screen and theme, is not decidable
from a mockup or a test, so Task 10 gains a step that settles it against real
cards, in both themes, with the guidance to widen the bar before touching the
user's own colour choices.

0 files changed, 0 insertions, 0 deletions