UnigramDev/Unigram/develop • 0b0c96f • 11 files, +383/-95
Route files through the handler on the pointer path too

updateFile and file are re-entered through ClientResultHandler rather than
parsed inline, so a file is read into the instance the app already holds -
they arrive by the hundred on every history page, nearly always for an id
already seen. The Utf8JsonReader path has always done this; the pointer path
parsed them fresh, which would have quietly stopped the dedupe the day it was
switched on.

That interface lives in the app, so TdJsonReader and PtrClientJson move with
it to Telegram/Td/ and are linked into the three benchmark hosts instead of
the other way round. Nothing in PtrClientJson refers to generated code now -
the FromPtr(byte*, int) entry point is emitted beside DoFromPtr - so both
files build with TdPointerParser still off, which is where the app stays.

.NET Native validates and the ratios hold: updateFile 2.70 us against 1.09,
a 50-message page 444.7 us against 182.8. Generated output with the pointer
mode off is byte for byte unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • bdc68ee • 8 files, +5/-136
Drop x86 from the solution

x64 and ARM64 are the only architectures shipped - the bundle has been x64 alone
for a long time, and Telegram.Stub was already built for those two only - so the
x86 configurations were carried by every project without ever producing anything.
Out of the solution, the app, the packaging project, both native projects, the
vcpkg triplet selection and Build.ps1's default arch.

The C# project's Win32 conditions went with them. $(Platform) there is x86, x64 or
ARM64 and never Win32, so both branches of TelegramTdPlatform were unreachable and
the property itself unused; OpenSSLPlatform collapses to the one form that ever
applied. Telegram.csproj's default platform becomes x64, which is the fallback the
packaging comment above ShouldUnsetParentConfigurationAndPlatform refers to.

Libraries/rlottie/x86 held a winmd with no RLottie.dll or .pri beside it, so
nothing could have linked against it either way.

Not built - the change is confined to configurations that produced no output.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram