Carry an optional blurhash on each attachment

[Bilb]

Opened against the attachment-availability branch of this fork, so the base is the branch this actually builds on. Stacked on #2 (drop attachment captions), which merges first, so the diff below carries its commit too. Only the last two commits belong here.

Adds an optional per-attachment blurhash: a short string encoding a blurred preview, so a recipient can draw a placeholder with the right colours before the file arrives. No Session client has one today.

libsession carries it, it does not compute it

This is the crux, and it is the existing argument rather than a new one. attachment.hpp already says width and height are the caller's to supply "because libsession cannot read them - deriving them means either an image library or hand-written header parsing of untrusted files". Encoding a blurhash needs exactly that decoder, so the field sits beside those two for the identical stated reason.

Open question for maintainers, raised deliberately rather than left implicit: nothing produces a blurhash today, so the field will be null for every real message until some sending client fills it. Whether libsession should eventually take on an image dependency and generate these itself - which would also settle thumbnailing, the other thing that comment defers - is your call, not this PR's. It only makes the field exist.

What it adds

• blurhash on OutgoingAttachment and Attachment (include/session/client/attachment.hpp)
• a blurhash TEXT column on message_attachments, appended at the end of the table, plus src/client/schema/007_attachment_blurhash.sql
• the four positional statements in src/client/client.cpp: the attachment read, the outgoing write, the outgoing protobuf build, and the incoming write
• optional string blurhash = 12 on AttachmentPointer
• round-trip and length-cap tests in tests/test_client/attachments.cpp

Field number

12, because 11 is caption and is reserved by the PR below this one. Nothing renumbers.

Length is capped at 28

A blurhash's length is fixed by its component counts as 4 + 2 * numX * numY, so 28 characters is a 4x3-component hash and the cap admits everything up to that. Deliberately conservative: 4x3 is what is wanted now, and raising it later is a one-line change that costs nothing on the wire, since the column is TEXT and the protobuf field is an unbounded string either way.

It is a bound on what a remote peer can put in the database, not a parse. The string stays opaque: nothing checks its base83 alphabet, and nothing checks that its length agrees with the size flag it declares. There is a comment saying so, because the obvious "improvement" is to turn it into a validator and that would contradict the point of the field.

The two directions differ on purpose. An over-long blurhash arriving from a peer is dropped - the attachment is stored intact without it, because a placeholder is decoration and losing it must not cost someone the file. An over-long one handed to send_message throws std::invalid_argument from _require_readable, on the calling thread, for the reason already written above that function: a caller's mistake belongs where it was made rather than in a message that has been stored and shown.

Verification

testAll: 407 cases, 25,758,679 assertions, all pass. utils/format.sh verify clean. Protobuf regenerated with protoc 3.21.12, matching the stamp in the committed .pb.h, so the generated diff is the new field and the _has_bits_ shift and nothing else.