UnigramDev/Unigram/develop • 8fdb141 • 7 files, +139/-23
Check whether a file still exists off the TDLib thread

1,152 of these ran during app start and cost 74 us each - seven times what
parsing a whole update costs - which made them a third of everything the TDLib
thread spent parsing. They are I/O and an app container access check, so no
build makes them cheaper; the only thing wrong with them is where they happen.

Nothing waits on the answer. The single outcome is a DeleteFile that TDLib acts
on whenever it arrives, so first sight of a downloaded file now queues the path
and a drain does the syscalls. One drain at a time: these arrive in bursts of a
thousand and a work item each would be a thousand thread pool hops for calls
that queue behind one another on the disk anyway. The same queue takes the
other first-sight check, in ProcessFile.

TdExtensions.Update stays synchronous - its caller acts on the answer instead
of sending a request about it.

NativeFile.Exists replaces NativeUtils.FileExists at all three call sites: one
P/Invoke to GetFileAttributesExFromAppW, which is what the C++/WinRT method
called anyway. Verified against the real export - the struct marshals to the
36 bytes the C layout wants, and a directory still reads as existing, as it did
before. The native method is now unused and can go on the next Telegram.Native
rebuild.

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

UnigramDev/Unigram/develop • 53efd5c • 1 files, +8/-5
Note the file check deferral in the resume section

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

UnigramDev/Unigram/develop • c72b366 • 3 files, +18/-8
Give the modern build libvlc's plugins

UnigramUsesVcpkg is matched on project name, and Telegram.Modern was not in the
list, so neither the vcpkg runtime DLLs nor UnigramAddVlcPlugins applied to it.
libvlc.dll was there and its plugins were not, which is a native death with no
managed error report to show for it - the crash Fela hit on video.

Adding the project to that list is the whole fix; the plugin tree then arrives
through the same target Telegram.csproj uses, keeping the plugins\<category>\
shape that plugins.dat records.

It also means vcpkg supplies the shared runtime, which collided with the sixteen
ffmpeg and libvlc DLLs copied out of x64\Release\Telegram.Native (NETSDK1152).
Only Telegram.Native.dll, Telegram.Native.Calls.dll and their .pri files come from
there now - the arrangement Telegram.csproj already had. Telegram.Td.dll goes with
them: the shipping package does not carry it either.

Published, registered and launched: the app starts and stays up. Whether video
plays is Fela's to say.

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

#unigram

UnigramDev/Unigram/develop • 35b04e1 • 1 files, +26/-2
Write down where the calls window stands

Everything else Fela tried works: stickers, animations, WebView2, VLC and
secondary windows. Calls do not - no video, no lottie - and the exceptions behind
it are caught, so ErrorReports stays empty.

Records what the blob waves rule out. They animate, and they run off the same
per-view CompositionTarget.Rendering that AnimatedImage uses, so the frame driver
is not the problem and the surface path is.

Also adds the Unigram* -> Telegram* property rename to the cleanups.

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

UnigramDev/Unigram/develop • 1bc5aaf • 1 files, +6/-0
Log the exceptions the XAML handler swallows

OnUnhandledException marks almost everything handled and returns, so a handled
exception leaves no trace at all unless Diagnostics.ShowMemoryUsage happens to be
on, in which case it goes to a popup. That is how the calls window fails on .NET
10: something in AnimatedImage throws, the app carries on, and neither the log nor
ErrorReports has anything to say about it.

Logger.Error rather than TrackError: the app survived these, and a crash report
would claim otherwise. At the default packaged verbosity it reaches tdlib_log.txt,
which is readable after the fact.

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

UnigramDev/Unigram/develop • adcdff1 • 1 files, +19/-1
Register rendering on the presenter's own loader

AnimatedImageLoader.Current is [ThreadStatic], so RegisterRendering was resolving
whichever loader belonged to the calling thread, while every other call in the
presenter goes through its own _loader - Load, Remove, Activated, PopupActivated.
When the two differ, the presenter joins the wrong view's rendering list and its
WriteableBitmap is invalidated from that view's thread:

COMException 0x8001010E (RPC_E_WRONG_THREAD)
at WriteableBitmap.Invalidate()
at AnimatedImagePresenter.DrawFrame() AnimatedImage.cs:1499
at AnimatedImageLoader.OnRendering() AnimatedImage.cs:1827

which is what leaves the call window without video or lottie. The call was always
illegal; .NET Native called through the raw pointer and never checked, CsWinRT
does.

The off-thread path also logs, because it should not happen: something is calling
in from another thread, and the log will name the case rather than leaving it to
inference.

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

UnigramDev/Unigram/develop • 870308e • 1 files, +20/-0
The file checks moved, and the parse shows it

Same page, next startup: file handling 0.086s to 0.007s, 34% of the parse to
4%. The checks themselves cost what they always did - 1,080 of them, 0.094s,
87us each - they are just not on the TDLib thread any more. What is left is the
dictionary, the publish and the enqueue, 0.6us per update.

Also notes what the Reader/Pointer A/B will not show: both modes start timing
after the copy and the terminator scan, which the pointer path deleted, so it
compares parser against parser and understates the change to Receive.

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

#unigram

UnigramDev/Unigram/develop • b162d28 • 1 files, +0/-3
Drop the packaging project's pre-build event

It only ever ran inside Visual Studio. Under MSBuild ProjectDir and
ConfigurationName are empty, so it expanded to

UpdateManifest.ps1 -path "\" -config "" -mode "SideloadOnly"

which PowerShell read as one escaped argument, Resolve-Path rejected, and git
answered "cannot change to 'rev-list'". The script's TryParse guard then exited
without touching anything - silently, and with the build reporting success. The
package inherited whatever version the manifest already carried, which is how
two different builds ended up stamped 12.10.0.13894 and one overwrote the other.

Build.ps1 already calls UpdateManifest.ps1 itself before invoking msbuild, which
is the call that works, so this was a duplicate of it that could only fail.

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

UnigramDev/Unigram/develop • 6d23cf4 • 1 files, +39/-3
Pin down why the call window does not animate

It is the Windows SDK XAML projection, not the app. A CompositionTarget.Rendering
handler subscribed on a secondary view runs on the main view's thread: measured in
a throwaway app (subscribed on 5, ran on 4) and matched by the app's own log, which
pairs a presenter whose bitmaps were built on thread 23 with a DrawFrame on thread
4.

Microsoft.Windows.UI.Xaml.dll caches the statics in a plain static field and
carries no ThreadStatic or ThreadLocal anywhere, so the first view to touch
CompositionTarget owns it for the process and everyone else's add_Rendering
registers against that view's core. No CsWinRT property covers it.

That also explains what looked contradictory: the call's blob waves animate because
Composition objects are agile, while lottie and video die on WriteableBitmap, which
is not - RPC_E_WRONG_THREAD, swallowed by the XAML handler.

Three options written down, smallest first. Nothing changed in the app yet.

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

UnigramDev/Unigram/develop • 87a294a • 2 files, +34/-12
1.56x in the app, and the Utf8JsonReader set stops being built

Two startups differing only in TdParsers: 87.4 MB/s through Utf8JsonReader
against 136.4 through TdJsonReader. The corpus says 2.4x for the same two
parsers on the same toolchain, so the app sees about two thirds of it.

The gap is everything the change does not touch. Solving for it puts the
reader-dependent work at 2.9 ms/MB and the shared part at 4.4 - 60% - which is
building the object graph and, mostly, a GC that promotes objects the app goes
on to hold, where a benchmark loop sweeps them at gen0. A corpus ratio is an
upper bound on what a parser change buys in situ.

Worth ~105 ms of TDLib-thread time on a startup that size, on top of the ~85 ms
the file-check deferral took off it.

So TdParsers goes to Pointer: 44,508 generated lines and ~500 hand-written ones
stop being compiled, and the app carries one parser. Reader walks it back in
one word - nothing was deleted, and Both is still there for the benchmark.

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

#unigram

UnigramDev/Unigram/develop • b2ec787 • 1 files, +6/-0
Carrying both parsers costs compile time, not binary size

Three x64 bundles built the same way: Reader 77,228,975 bytes, Pointer
77,754,662, Both 77,749,472. Both and Pointer are within 5 KB, because ILC
strips the set nothing calls. The 526 KB between Reader and Pointer is the
pointer parsers being larger native code, the same 40% the line counts show.

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

UnigramDev/Unigram/develop • 85ee4c2 • 3 files, +131/-19
Register CompositionTarget.Rendering per view

Verified by Fela: video and lottie both work in the call window again.

CsWinRT keeps one event source per statics object for the whole process, so a
second view's CompositionTarget.Rendering += never reaches add_Rendering - the
delegate is appended to the registration the first view made, and the handler runs
on that view's thread. Every secondary view's frame callback lands on the main
view's thread. Composition objects do not mind, being agile, which is why the call
blobs animated throughout; WriteableBitmap does mind, and DrawFrame died on
RPC_E_WRONG_THREAD.

CompositionTargetRendering registers through the ABI instead, so each view gets a
registration of its own. The statics object is a process-wide agile singleton -
measured, along with its IAgileObject - so the call runs on the calling thread and
registers there. Proved in a throwaway app first: in the same run, the projected
subscription fired on view 1's thread and the ABI one on view 2's.

Reported as https://github.com/microsoft/CsWinRT/issues/2524.

Also drops the marshalling branch added to RegisterRendering earlier, which was
aimed at the wrong cause and never once fired; the presenter's own _loader stays.

Left alone, and noted in the todo: CompositionVSync, VisualUtilities,
PremiumProgressBar, PremiumSlider and GiftCraftPopup still subscribe through the
projection. Same latent bug, invisible so far because they only touch Composition.

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

UnigramDev/Unigram/develop • 388e015 • 8 files, +114/-66
Alias CompositionTarget rather than #if every call site

Fela's idea, and a better one: CsWinRT.cs already keeps the global usings, so the
stand-in goes in there and the twenty call sites stay written the way they were.

#if NET9_0_OR_GREATER
global using CompositionTarget = Telegram.Common.CompositionTargetImpl;
#else
global using CompositionTarget = Windows.UI.Xaml.Media.CompositionTarget;
#endif

Aliasing in both directions pays for itself twice: .NET Native binds to the real
type as before, and the alias settles the ambiguity with
Windows.UI.Composition.CompositionTarget, which is the only reason those call sites
spelled the namespace out. They lose the prefix and a comment explaining it, so the
net change is shorter code than before the port.

That also carries the fix to everything else that draws per frame -
CompositionVSync, VisualUtilities, PremiumProgressBar, PremiumSlider,
GiftCraftPopup - which until now was running on the first view's thread in any
secondary window and getting away with it only because Composition objects are
agile.

Rendered goes through the ABI too, via ICompositionTargetStatics3. Forwarding it to
the projection, as it was a commit ago, left one honest half and one broken half in
a type that exists to fix exactly that.

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

#unigram

UnigramDev/Unigram/develop • 068f474 • 1 files, +9/-4
Note that the alias covers every frame callback

The todo still said CompositionVSync and VisualUtilities were left on the broken
path; the alias in 6a2466fb3 took them with it, along with Rendered.

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

UnigramDev/Unigram/develop • ea510bd • 2 files, +0/-41
Removed unused code

UnigramDev/Unigram/develop • 8de24ae • 15 files, +33/-281
Make the app AOT-clean

The whole trim surface of the app was five warnings in two files, and both were
dead weight.

TypeCrosserGenerator is deleted: nothing called it. Its one call site was
[Conditional("DEBUG")], so Release stripped the call but still compiled the body,
and ILC saw Assembly.GetTypes() over the TDLib types. Note that Conditional still
binds the name, so #if DEBUG around the class does not compile - the reference has
to go with it, and the Compile entry in Telegram.csproj too, which is not globbed.

TypeContainerGenerator has no call sites at all, so #if DEBUG is enough for it, and
there is now a todo to rewrite it as a source generator. Its GetConstructors and
GetProperties are the last reflection left in the app.

Fourteen classes that cross the WinRT ABI are marked partial, which is CsWinRT1028:
without it the marshalling code cannot be generated at build time and falls back to
reflection, which is what AOT trims away. Two of them are LottieGen output, so
regenerating those icons will drop the keyword again.

PublishAot moves into Telegram.Modern.csproj. Passed on the command line it is a
global property, so it flows into the ProjectReference and Telegram.Generators -
netstandard2.0 - fails with NETSDK1207.

Compile verified on the modern project; the ILC run to confirm the warning count is
still to come. .NET Native untouched by all of this bar the two deletions.

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

#unigram

UnigramDev/Unigram/formatted-text-block-dates • b6cc86e • 3 files, +347/-6
Anchor rendered indices to the paragraph a block starts at

The fast path left _indexMap null on the grounds that a plain single run maps
1:1 onto StyledText offsets. That only holds for a block whose first paragraph
is the message's first: MessageTextBlock gives every plain paragraph sandwiched
between typed ones its own block, and those render a slice of a shared
StyledText starting somewhere in the middle.

With no map, the converters returned the rendered index unchanged, so copying a
selection from such a block returned text from the start of the message, word
and paragraph expansion resolved against the wrong paragraph, and the search
highlight landed past the end of the block.

_origin is set beside _first/_last so it is correct before every early return
and on both paths - the slow path can also end up with an empty map when every
entity is dropped by the length guard, and that takes the same fallback.

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

UnigramDev/Unigram/formatted-text-block-dates • 7b39d50 • 2 files, +24/-12
Give the code block tokenization an identity that does not restart

_templateExecuted was doing two jobs: the "text has been applied" flag OnLoaded
tests, and the token that ProcessCodeBlock compares against after its await.
OnUnloaded resets it, so the second job was an ABA - execution 1 is handed out
again after every unload, and a tokenization started before it resumes, matches,
and calls ClearCollection on inlines whose Paragraph is by then back in the
shared pool, wiping whichever block dequeued it.

The async guard now uses its own never-reset counter. That leaves the flag as a
flag, so it is a bool.

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

UnigramDev/Unigram/formatted-text-block-dates • ecaf440 • 7 files, +34/-22
Build the monospace font chain once, in Theme

Nine sites spelled out "Cascadia Mono, Consolas" and built a FontFamily from it.
FormattedTextBlock meant to memoize its own, but the local it returned was never
assigned, so it allocated one per monospace entity - and ProcessCodeBlock, being
recursive, one per node of the token tree. Six of the others sit inside a loop
over entities, so they allocated one per code span they rendered.

Theme already owns XamlAutoFontFamily and rebuilds the families that embed it in
UpdateEmojiSet, which is the only place the chain can change, so the family
belongs there and everything reads Theme.Current.MonospaceFontFamily.

Those six spelled the chain without the fallback tail, and now inherit it: a
character the monospace faces don't cover renders through the text and emoji
fonts instead of the system default.

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

#unigram

UnigramDev/Unigram/formatted-text-block-dates • 62ce609 • 2 files, +25/-6
Stop building the syntax colour tables per text block

_light and _dark held 28 entries each and were instance fields, so every
FormattedTextBlock in the app carried both - the chat list, replies, web page
previews, all of them - to serve the rare one that renders a code block. Color
is a value type and the tables are never written to, so they are static.

The brushes built from them can't be shared the same way, since a
DependencyObject belongs to the thread that created it and the app runs a XAML
thread per view, but they can wait until a code block asks for one.

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

UnigramDev/Unigram/formatted-text-block-dates • 1eb61cb • 2 files, +24/-7
Set the I-beam on the way in, not on every pointer move

_textSelectionIBeam was assigned and never read, so an Extended block set
CoreWindow.PointerCursor - a marshalled call, plus a CoreCursor allocation - for
every pointer sample over its text.

Testing it is not enough on its own: a Hyperlink puts its own Hand cursor up, so
once the pointer crosses one, ours is no longer what is on screen. The flag is
cleared there, or moving back onto text would skip the I-beam and leave the Hand.

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

UnigramDev/Unigram/formatted-text-block-dates • f35945b • 2 files, +31/-12
Measure an expandable quote once per width, not once per pass

MaxLines is a native text layout over the whole quote, and it ran on every
measure - so on every window resize and every InvalidateMeasure the bubble
takes - to answer a question whose inputs had not moved.

The text is compared by reference rather than by value, which is exact here:
GetParts returns the same instance until a relative date rewrites the paragraph,
and that is the one thing that can change the answer at a fixed width.

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

UnigramDev/Unigram/formatted-text-block-dates • 22a1d7a • 2 files, +42/-22
Allocate the entity collections only for text that has entities

Seven collections were built in the field initializers of a control that the
chat list, replies, web page previews and every message bubble instantiate.
Links, dates and spoilers are rare enough that those three are now null until
something is added; the active-element lists are not, because every rendered
block fills them.

All four active collections become List<T>: nothing can be added twice - each
element is newly constructed or dequeued from the pool, Recycle clears the
lists, and the one mid-render hand-back removes before it enqueues - so the
hashing bought nothing but the cost of a Contains that runs once per code block.

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

#unigram

UnigramDev/Unigram/formatted-text-block-dates • f07fe69 • 2 files, +39/-11
Keep the relative date timer from arming itself 68 years out

An item that was not due yet contributed its remaining time truncated to whole
seconds, so anything under a second contributed nothing. That is the normal
state of the one-second bucket - the timer can fire a hair early - and when it
was the only item, the minimum stayed at int.MaxValue and every relative
timestamp on the thread stopped updating until something else subscribed.

Rounds up now, and the return clamps, so an empty or fully-skipped set falls
back to a second rather than to the sentinel.

TextDate also stops being a record: .NET Native has no records, and as a
dictionary value keyed by its own Element it never needed value equality. The
EntityType member went with it, since only the constructor ever read it.

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

UnigramDev/Unigram/formatted-text-block-dates • fcde955 • 2 files, +25/-3
Retry the highlighters on load instead of losing them

ApplyHighlighters returns without doing anything when the inner RichTextBlock is
not loaded, and OnApplyTemplate calls SetText before that is true. Nothing put
them back: OnLoaded returns early on the very flag SetText had just set. If the
guard ever holds - and it is there because it once did - the spoiler cover for a
first render is simply never applied.

A flag is the answer that is correct whichever way the ordering actually falls:
no change if the block is already loaded, and the highlighters arrive a moment
late rather than never if it isn't.

Revealing a spoiler no longer calls SetQuery(string.Empty) either. SetText
reapplies the highlighters on its own now, so all that line still did was forget
the search term the user is looking at.

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

UnigramDev/Unigram/formatted-text-block-dates • bdd6431 • 2 files, +87/-132
Write the run property reset once

The two GetOrCreateRun overloads carried the same sixty lines of "set this or
clear it" for a pooled Run, which is the part that has to stay in step with what
NativeUtils does for a new one.

They are not merged into one: on the path that builds a Run, the range overload
hands the offset and length to NativeUtils and never materializes the substring,
so forwarding one to the other would have cost exactly the thing it exists for.
Each keeps its Run_Text line and its native call, and shares the rest.

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

UnigramDev/Unigram/formatted-text-block-dates • de73924 • 2 files, +26/-4
Make Clear reset the highlighters it claims to reset

Clear nulls the query and the spoiler, but the highlighters themselves live on
the inner RichTextBlock and it never touched that collection - and it ignored
the cached, marked and selection ones entirely.

It runs from MessageService.Recycle, on the Text block of every service message,
under a contract spelled out at the call site: whatever isn't reset is inherited
by the next message in that container. So a recycled service message could come
back wearing the previous one's spoiler cover.

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

#unigram

UnigramDev/Unigram/formatted-text-block-dates • b92d90f • 3 files, +92/-55
Say what these actually are

Spoilers build a Span and called it hyperlink, twice; UpdateSpoilers iterated
TextStyleSpoiler structs as hyperlink; RelativeDateService took a TextStyleRun
called Yolo through three signatures.

The two foreground property handlers were the same five lines under different
names - neither of which described what they do, which is recolour the links
still carrying the outgoing brush.

OnApplyTemplate drops _blocks once it has handed the XAML-declared Paragraphs to
the RichTextBlock, so re-templating cannot try to re-parent them, and skips a
non-Paragraph entry instead of adding null.

The Selectable header claimed an inline object counts as one unit in highlighter
space. It counts zero - the ZWNJ emitted next to it is the unit - which is what
WalkInlines does and what the index map assumes.

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

UnigramDev/Unigram/formatted-text-block-dates • fa1db16 • 2 files, +16/-2
Offset the query highlight by the host content in inline mode

An inline-mode block renders into a Span the host owns, behind whatever it put
in front - a sender name in a chat cell - while TextHighlighter indices count
from the start of the RichTextBlock. The spoiler ranges correct for that; the
query highlight did not, so it would have landed short by the length of the
prefix.

Would have, because nothing gives an inline-mode block a query today: the only
live query is MessageBubble's, and that goes to MessageTextBlock. This is right
by symmetry with the spoiler branch rather than by observation.

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

UnigramDev/Unigram/formatted-text-block-dates • f3fd2c0 • 1 files, +48/-2
Say why the five open items are open

Each of the remaining items is a decision rather than a patch, so the entry now
carries what I found while working through the rest: SetFontSize runs into the
undecided quote sizing question the TODO at :1127 already flags, the non-pooled
teardown has two fixes that each cost something real, and the last two want a
profiler and the layout cycle audit respectively.

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

UnigramDev/Unigram/formatted-text-block-dates • 76a6357 • 1 files, +11/-21
Close SetFontSize as by design

Its only caller is UpdateMockup, for the fake conversation in appearance
settings where the font size slider has to take effect without going back
through SetText. Those are one plain paragraph each, so the first paragraph is
the whole text - and no quote ever reaches it, which takes the caption size
question off this method entirely.

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

#unigram

UnigramDev/Unigram/formatted-text-block-dates • e7e25f0 • 2 files, +191/-55
Keep spoilers and copy offsets in step with relative dates

A relative date rewrites itself in place, and three things downstream are
expressed in coordinates that move when it does: the spoiler geometry, the
highlighter ranges that hide the text, and the index map the selection layer
reads. Only the first was maintained, from OriginalOffset plus a delta measured
against the source length - which is the total growth since the first render, so
applying it on every tick, and once per date, compounded. The ranges were a
commented-out block, and nobody had noticed the index map at all.

Geometry is now derived rather than stored: TextStyleSpoiler holds source
offsets and DisplayedRange works out where the spoiler currently sits from the
paragraph's runs, so any number of dates in any order land in the same place.

Rendered space is shifted instead, by the change since the last tick, from the
map segment each date now remembers - which is also what fixes copy in any
message with a relative date, spoiler or not.

Two more from the same root: a spoiler's range took the source length, so a
spoiler wrapping a date was short from the first render - it is now measured
from what was emitted. And the two halves of UpdateSpoilers disagreed about
whether the offset was date-expanded, which deriving per branch settles.

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

UnigramDev/Unigram/formatted-text-block-dates • a22e3b4 • 1 files, +226/-0
Add a test plan for both branches

Markdown covers most of it, since ParseMarkdown runs on send. Dates do not have
a markdown syntax, so those come from the composer's formatted date item, and
part C starts by confirming the entity survives the round trip at all - if it
does not, nothing downstream of it is testable that way.

Each item says what wrong looks like, because most of these fail by a couple of
characters rather than by crashing.

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

UnigramDev/Unigram/formatted-text-block-dates • f51bf97 • 2 files, +247/-30
Send the test messages from a script, and correct two cases

The Bot API does carry the date entity, as date_time with unix_time and
date_time_format. Worth knowing that unknown extra fields are accepted and
ignored, so a wrong field name leaves the format empty and the date renders as
plain text - it looks like the feature is broken rather than the request.

Two cases in the plan could not exist. A spoiler may not overlap a date: the
server splits the spoiler around it rather than rejecting the message. So a date
inside a spoiler is not a state the app can be given, and the stretch branch of
ShiftRanges is unreachable for dates - it stays live only for the marked and
cached highlighters, which the app builds itself.

The split is the better test anyway. T10 now sends a spoiler spanning a date and
gets two covers back, one either side, which have to do different things across
the same tick: the one in front stays, the one behind moves.

The script takes the token and chat as arguments and carries neither.

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

#unigram

UnigramDev/Unigram/formatted-text-block-dates • 42d021b • 1 files, +9/-0
Note that a spoiler cannot contain a date

Found while building the test set: the server splits a spoiler around a date
rather than letting them overlap. So the branch that stretches a spoiler around
a growing date is unreachable for dates, and stays live only for the marked and
cached highlighters, which the app builds itself.

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

UnigramDev/Unigram/formatted-text-block-dates • 090790a • 2 files, +45/-13
Anchor the dates in seconds, since the formatter counts seconds

I had read RelativeDate, which falls back to "just now", rather than
RelativeDateAgo, which is the one InAgo calls and which ends in
Declension(SecondsAgo, value). So the text does tick per second, and the width
changes at 2s, 10s, 60s, 2min, 10min and an hour.

Anchoring at eight seconds gives three width changes inside two minutes instead
of one, with the counter visibly running in between.

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

UnigramDev/Unigram/formatted-text-block-dates • 98d5640 • 3 files, +49/-8
Release the relative dates without waiting for Unloaded

ClearBlocks drops its blocks and leaves teardown to the Unloaded event, and
FrameworkElementEx only raises OnUnloaded for an element it saw Loaded on. A
block subscribes from SetText, which runs from OnApplyTemplate, which runs on
the first measure - before Loaded. Dropped in between, it never releases, and
what it holds is a registration in the thread-static RelativeDateService: the
block, its paragraph and its runs pinned for the session, still being ticked.

The other half needs no assumption about when Loaded arrives. The service is
keyed by the Run, and Runs come from the shared pool, so one registration that
outlives its block made that Run unsubscribable for good - every later block
that dequeued it had its date silently never update. Subscribe replaces the
entry now instead of skipping, since a Run being resubscribed always means the
old registration is dead.

Runs still return to the pool through OnUnloaded alone. A missed pool return
costs an allocation rather than a pinned graph, and giving Clear a second path
into the pool wants the recycling audit rather than a guess.

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

#unigram

UnigramDev/Unigram/record-session • a597f50 • 9 files, +1363/-1157
Give a recording an owner

The record button held four things: the gesture, the state of the recording, the
capture engine, and the decision of what to do with the result. The engine was a
thread-static singleton every loaded button subscribed to, so a recording started
in one chat drove the state of every other chat and story composer on the thread,
and QuantumProcessed was a single field that whichever button loaded last took
over and the first to unload set back to null.

ChatRecordSession now owns the state and the engine, one per button, which is one
per chat. What is left in the button is the press-and-hold gesture and its own
visuals.

Seven booleans and an integer interface state become three named states. The
fourth one - locked, then stopped - was only reachable through StopRecording(false),
which nothing ever called, so it went out along with the tri-state stop that
neither sent nor discarded what it recorded. Cancel and Complete say which they
are.

Elapsed comes off a monotonic clock rather than DateTime.Now, freezes while
paused, and starts when the capture device is actually open rather than when the
button was pressed. The pause state is reset when a recording ends instead of
leaking into the next one, and the bar detaches from the button on unload.

Permissions go through MediaDevicePermissions, which is what calls already use,
so granting access no longer costs the first press: the old check asked
DeviceAccessInformation and then returned false regardless, leaving the prompt as
the only thing that press did.

MediaCapture.Failed ends the recording instead of only logging it, and a press
too short to record now says so.

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

#unigram

UnigramDev/Unigram/swipe-to-go-back • c4edf3c • 1 files, +13/-0
Record that the series landed and what is still open

Tested in the app against the message set the script sends, including the
relative date and spoiler cases that were visibly wrong beforehand. Three items
stay open and each one says under its own entry what it is waiting on.

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

UnigramDev/Unigram/swipe-to-go-back • 630b883 • 10 files, +2/-2
Move the working notes into notes/

The reviews, to-dos and audits had grown to a dozen files sharing the root with
README, CHANGELOG and the rest. Only the two references that name a path needed
updating; the ones that merely name a file still read fine.

webrtc-uwp-review.md stays at the root for now - it has uncommitted edits that
are not mine to commit - as do the untracked notes.

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

UnigramDev/Unigram/swipe-to-go-back • 27791be • 2 files, +453/-3
Catch the collection marshalling errors at compile time

Every AOT failure so far but two has been a collection crossing the ABI with
no CCW vtable for its concrete type, and none of them warn: set_ItemsSource
returns E_INVALIDARG, which on a DispatcherQueue callback is a fail-fast, so
the log's tail is gone too. Two analyzer rules cover the class.

TG1001 is the boxed case - object, or a bindable interface with no element
type. TG1002 is an array of a value type that is not a WinRT fundamental,
which has to go through IReferenceArray. The line between them is whether the
compiler can see the conversion: a parameter typed IEnumerable<T> is one, and
CsWinRT generates the marshaller for it, which is why an array of a
runtimeclass reaches ConfigurePositionXInertiaModifiers intact.

Both are silent on .NET Native, where the attribute they suggest does not
exist and neither does the problem.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

UnigramDev/Unigram/swipe-to-go-back • 1e20ebf • 3 files, +54/-6
Register what the analyzer found, and fix the array it found

The ItemsSource block was a grep sweep of mine, and two of its entries named
the wrong type: what those popups assign is the DiffObservableCollection, and
the List beside it is only the backing store. Replaced wholesale by TG1001's
output, so it can be regenerated rather than extended by hand.

StealthModeFeature has to be internal to be named in the attribute.

MessageForwardHeader is TG1002, and it is the forward-header crash the notes
record as fixed - GetParts returns a List now, but this one builds its own
array.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

UnigramDev/Unigram/swipe-to-go-back • 3985a94 • 1 files, +4/-1
Log the exception, not where it was caught

Logger.Exception passed Environment.StackTrace, which only says where the
catch is - and the caller attribution already gives that. The exception's own
message and stack went nowhere.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#unigram

UnigramDev/Unigram/swipe-to-go-back • b21e5bc • 3 files, +38/-11
Switch the modern projects between the two identities

ModernIdentity=Original carries the identity Telegram.csproj and
Telegram.Msix ship, which is what a beta for testers needs; Alternative, the
default, installs beside them. The property is in the generated manifest's
path as well as in the conditions, because the target is incremental on the
source manifest and flipping the property alone would reuse the old one.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

UnigramDev/Unigram/swipe-to-go-back • c825e6b • 2 files, +7/-0
Keep the ProgressBar cast the trimmer cannot see

Nothing in the app constructs a ProgressBar - both uses are
GetTemplateChild(...) as ProgressBar - so the metadata the cast needs is
trimmed and the field comes back null rather than throwing. VideoContent then
dereferenced it on every position change, once per frame inside a catch, and
again in Play_Click; PollOptionContent has the same shape on its vote bars.

CsWinRT1034 named both sites. I had concluded the cast-only set was empty and
was wrong: of the 117 types the warning covers, 67 are never constructed in
C#, and the ones reached only through GetTemplateChild are all in this
position.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

UnigramDev/Unigram/swipe-to-go-back • 72303c1 • 10 files, +212/-57
Root every projected cast from the casts themselves

The RCW metadata a cast needs is only reachable through the cast, so trimming
takes it and `as` yields null instead of throwing. That is a null template
child and a feature that silently does nothing: ProgressBar cost a day of an
exception per frame, and ItemsPresenter the chat list's folder swipe, both
flagged by CsWinRT1034 all along among 1800 others.

CsWinRT gathers every [DynamicWindowsRuntimeCast] into one module initializer
of DynamicDependency attributes, so the attribute's placement never mattered -
only the type. Emitting those attributes from a generator is no use, since
generators all see the original compilation; this emits the initializer
itself, from the as/is/cast expressions. 222 types against the 116 CsWinRT
warns about, because it also covers patterns and casts it can prove nothing
about.

Nothing declares this by hand any more: the six annotated methods and the
.NET Native dummy attribute are gone. The generator emits nothing when
ModuleInitializer or DynamicDependency do not resolve, which is that build.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

#unigram

UnigramDev/Unigram/swipe-to-go-back • 16a26bd • 7 files, +408/-9
Pull a back chip in from the edge of the detail

A left-to-right swipe over the detail pane brings in a circular back chip and,
past 72px, navigates back. Only the chip moves: revealing the master would mean
measuring the whole chat list at the moment the finger starts moving, since it is
collapsed while a chat is open, and a Frame navigation cannot be scrubbed anyway.

MessageSelector already owns a horizontal tracker over every bubble, and it wins
the manipulation: its source claims the contact first and chaining is off. So the
MasterDetailView does not compete for it. It owns the chip and binds it, by
expression, to whichever tracker is driving - MessageSelector's over a bubble, its
own everywhere else. Expressions may reference a tracker from anywhere in the
compositor, so nothing runs per frame on the UI thread.

The bubble already stays still under such a swipe: its offset expression reads
CanShare, which is false whenever back has the direction. Only MinPosition was
holding it at zero.

Back takes the direction Share is not using, so a user who wants it everywhere
turns Share off, and no setting is ever on while doing nothing.

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

UnigramDev/Unigram/swipe-to-go-back • 5c8d8da • 4 files, +85/-17
Make the back chip harder to miss

Fela asked for something catchier. It is 40px rather than 30 and travels the
full width of its own diameter, it swings upright from -30 as it comes in, and
past the threshold it latches into an armed state - scale pops to 1.15 and
opacity goes to full - so releasing feels committed rather than guessed at.

The tracker is clamped at the threshold, so progress rests at exactly 1 for as
long as the gesture is past it. Testing that rather than a distance means the
armed state latches on and stays on, instead of flickering at the boundary.

Still one expression per property, so none of this costs a frame.

The fill colour is now refreshed per gesture. The chip is built once and lives
for the window, so it kept whatever accent it was born under across a theme
change.

Carries the generated Resources.cs and .resw for the SwipeGoBack string added
in the previous commit.

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

#unigram

UnigramDev/Unigram/swipe-to-go-back • c4e3c8c • 2 files, +84/-31
Carry the gesture inside the page's scrolling host

On settings pages the chip only appeared in the title strip and nowhere in the
page itself. A vertical ScrollViewer takes the touchpad pan before any ancestor
sees it, and the source lives on DetailRoot, which is an ancestor of the page -
so the header, sitting outside the scroller, was the only place left.

The chat history was never evidence to the contrary: what works there is
MessageSelector's source, which is a descendant of the scroller and so wins the
contact. This does the same thing deliberately, putting a second source on the
scrolling host's content element and adding it to the same tracker. Rails and an
X-only source mode leave vertical panning to the ScrollViewer, as they already
do in the chat history.

Only ScrollViewer hosts. A ListViewBase one would need its ItemsPanelRoot, which
does not exist until the list realises, and the list that matters is the chat
history.

The old source is dropped on the way in rather than on the way out, because
OnNavigating is never subscribed.

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

UnigramDev/Unigram/swipe-to-go-back • 17d603c • 2 files, +68/-5
Reach the gesture to the foot of a short page, and slide back from the left

Moving the source inside the scrolling host fixed only the long pages. Privacy
and Security worked; Power Saving and Advanced did not, and those are the two
shortest settings pages in the app. A ScrollViewer arranges content shorter than
the viewport at its desired height, so the source reached the rows and stopped -
everything below the last one is bare scroller, which takes the pan.

The source has to sit inside the scrolled content, since that is the only thing
that beats the scroller to the contact. So the content is what has to cover the
viewport: its MinHeight now comes from the host's ViewportHeight, kept current on
SizeChanged. Nothing else moves, because the extent still matches the viewport
and a short page stays unscrollable. ViewportHeight is 0 at OnNavigated, so
SizeChanged is where the height first lands rather than only where it is kept.

Committing the gesture now navigates with a FromLeft slide, mirroring the
FromRight that TLNavigationService uses going forward - the default entrance
transition reads as unrelated to the finger that asked for it. Gated on the power
saving policy, which FrameFacade applies to Navigate but not to GoBack, so
nothing else would have stopped it animating.

Drops a comment that claimed this route lets an INavigablePage answer for
itself. It does not: NavigationService.GoBack goes straight to the frame and
never reaches OnBackRequested. That matches the visible back button, which takes
the same route.

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

#unigram

UnigramDev/Unigram/swipe-to-go-back • 2cd789f • 2 files, +54/-17
Give a short settings page an area that hit-tests

SettingsStickersPage works, and its ScrollingHost is a TableListView, so none of
the scrolling-host code runs for it at all. An ancestor source does get the pan
there, which means the scroller was never the whole story.

The discriminator is hit-testing. SettingsPanel is a bare Panel, and a Panel with
a null Background does not hit-test its own area. Its rows hit-test themselves,
which is why the gesture always worked on a page long enough to be all rows and
nowhere on the empty part of a short one - and why Stickers works from the other
direction, its ListViewItems being real content. With no hit there is no element
to walk up from and no source is ever found.

So the height added in the last commit bought nothing on its own. It needs a
Background to go with it, and Transparent paints the same as null.

Also flips the transition to FromRight. The frame inverts the effect on a back
navigation, so FromRight is what slides the uncovered page in from the left, and
it is the same value TLNavigationService passes going forward.

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

UnigramDev/Unigram/swipe-to-go-back • 73c6a75 • 2 files, +46/-96
Take back the two fixes for a cause that was not the cause

Advanced and Power Saving fail over text and buttons, not only over empty space,
so neither the content falling short of the viewport nor a bare Panel declining
to hit-test its own area can be what is stopping them. Both were guesses, both
mutated pages this control does not own, and neither moved the symptom.

The scroller theory that started the sequence is doubtful too: SettingsStickers
works, and its host is a TableListView that ConfigureBackGestureContent skips
altogether, so an ancestor source is evidently enough somewhere. The source it
adds is left in place but is not to be treated as load-bearing.

What is left is a page whose XAML matches, element for element, pages that work.
The notes record what has been ruled out so the next attempt starts from
evidence rather than from another reading of the markup.

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

UnigramDev/Unigram/swipe-to-go-back • 3bc5ef7 • 2 files, +47/-16
Keep the scroller manipulable so the pan stays a manipulation

Advanced and Power Saving take the gesture once the window is small enough for
their content to overflow, and refuse it at any size where it fits. That is the
whole of it.

ScrollMode.Auto turns the manipulation off when there is nothing to scroll, and a
touchpad pan over an element that cannot be manipulated is never classified as
one - so no interaction source is consulted anywhere up the tree and the gesture
is absent rather than misrouted, which is why no chip ever appeared.

Every settings page declares VerticalScrollMode="Auto". The difference between
the ones that worked and the ones that did not was never the markup, which is
identical, but whether the content happened to overflow at the size the window
was. Enabled holds the manipulation open regardless of extent, and costs nothing
here: there is still nothing to scroll, so nothing becomes scrollable that was
not already.

The declared value is restored when the page is left.

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

#unigram

UnigramDev/Unigram/swipe-to-go-back • 661bff2 • 1 files, +6/-2
Record that the gesture is working on a build

Confirmed across the chat history, profile and settings, including the pages that
refused it while their content fitted the window.

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

UnigramDev/Unigram/swipe-to-go-back • a57c772 • 2 files, +100/-45
Draw the back indicator out of the edge instead of sliding it in

A circle arriving over the page was the chat list's vocabulary borrowed wholesale,
and it read as stock even after it was made larger and given an armed state.

It is a pill now, and the edge is where it comes from rather than somewhere it
passes. It starts as an 18px sliver whose right edge sits exactly on x=0, so
there is nothing to see until the finger moves, and it lengthens as it is pulled.
Height grows with it, 40 to 48, so the shape reads as elastic rather than as
something arriving at a fixed size. The corner radius stays at half the height,
so it is a true capsule the whole way and lands on a circle exactly when width
and height meet at the threshold - which is also the moment its left edge clears
the boundary and it detaches from what it grew out of. That detach is the armed
state, with a scale pop and full opacity behind it.

The arrow waits until the pill is long enough to hold it, then fades in and
swings upright.

All of it is one expression per property, the geometry's Size and CornerRadius
included, so nothing here costs a frame on the UI thread.

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

UnigramDev/Unigram/swipe-to-go-back • 26fd71b • 5 files, +122/-136
Put the chat list's indicator back, and frost all three

The pill was worse than what it replaced. This is ChatListListView's indicator on
its own numbers - in from the edge over 55px, growing 0.8 to 1, fading the whole
way - mirrored on X, since ArrowLeft.png is drawn for the right-hand edge and the
chat list flips it the same way for the one it brings in from the left.

The fill is the one thing that is new. The circle is a SpriteVisual painted with
SolidGaussianBrush, so it is frosted over whatever sits behind it rather than a
flat 40%-alpha grey, and the same goes for the ChatListListView and
MessageSelector indicators, which are the same 30px circle.

A shape fill cannot carry an effect brush - CompositionSpriteShape takes colour
and gradient brushes only - so the circle becomes a mask over the effect instead,
drawn once through a CompositionVisualSurface. That keeps the antialiasing a
geometric clip would have thrown away. The mask is applied either way, so where
materials are switched off the fallback is still a circle and not a square.

SolidGaussianBrush keeps its XAML behaviour and now builds its graph through a
static factory the three call sites share.

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

#unigram

UnigramDev/Unigram/develop • 4daed16 • 2 files, +19/-6
Fix layout cycle

UnigramDev/Unigram/develop • a380fa4 • 1 files, +0/-7
Remove dead method

UnigramDev/Unigram/develop • fd5f90c • 6 files, +929/-141
Encode voice messages while they are recorded

A voice message was captured twice and encoded three times: a MediaFrameReader
already held every sample in memory to drive the blob, while LowLagMediaRecording
wrote the same audio to a WAV that was read back and re-encoded to Opus when the
message was sent.

OpusOutput.WriteFrame has been there the whole time and had no caller. The reader
now feeds it directly, so the file that lands on disk is already the file that
gets uploaded, and the duration is counted from the samples rather than taken
from MediaCaptureStopResult and truncated to a whole second.

The encoder is 48kHz mono and a frame source hands over whatever the endpoint
runs at, so this only applies when the format fits, or can be set to fit. It
falls back to the old path otherwise, because playing back at the wrong speed is
worse than transcoding.

Waveforms are sent now. They were computed and then dropped for Array.Empty,
which hid a bug in the accumulator: the bucket peak was never reset, so every
bucket held the running maximum of the whole recording and the waveform could
only climb.

The reader also had to stop dropping frames. Realtime acquisition and a 64ms
gate that returned before touching the buffer were fine for a blob and would
have cut holes in a recording, so it is Buffered now and only the level
notification is rate-limited.

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

UnigramDev/Unigram/develop • dba8a19 • 1 files, +11/-6
Never renegotiate the capture format for a video message

The blob is animated for voice and video alike, so the frame reader runs in both
modes, and the format negotiation added with the sink was running in both too.

A video message records through MediaCapture. Changing the format of the audio
source it is about to record from, to suit an encoder that isn't involved, would
change what lands in the mp4 for the sake of a level meter.

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

#unigram

UnigramDev/Unigram/record-session • 8c05584 • 6 files, +929/-141
Encode voice messages while they are recorded

A voice message was captured twice and encoded three times: a MediaFrameReader
already held every sample in memory to drive the blob, while LowLagMediaRecording
wrote the same audio to a WAV that was read back and re-encoded to Opus when the
message was sent.

OpusOutput.WriteFrame has been there the whole time and had no caller. The reader
now feeds it directly, so the file that lands on disk is already the file that
gets uploaded, and the duration is counted from the samples rather than taken
from MediaCaptureStopResult and truncated to a whole second.

The encoder is 48kHz mono and a frame source hands over whatever the endpoint
runs at, so this only applies when the format fits, or can be set to fit. It
falls back to the old path otherwise, because playing back at the wrong speed is
worse than transcoding.

Waveforms are sent now. They were computed and then dropped for Array.Empty,
which hid a bug in the accumulator: the bucket peak was never reset, so every
bucket held the running maximum of the whole recording and the waveform could
only climb.

The reader also had to stop dropping frames. Realtime acquisition and a 64ms
gate that returned before touching the buffer were fine for a blob and would
have cut holes in a recording, so it is Buffered now and only the level
notification is rate-limited.

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

UnigramDev/Unigram/record-session • b62a441 • 1 files, +11/-6
Never renegotiate the capture format for a video message

The blob is animated for voice and video alike, so the frame reader runs in both
modes, and the format negotiation added with the sink was running in both too.

A video message records through MediaCapture. Changing the format of the audio
source it is about to record from, to suit an encoder that isn't involved, would
change what lands in the mp4 for the sake of a level meter.

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

#unigram

UnigramDev/Unigram/record-session • 16ec88e • 9 files, +1363/-1157
Give a recording an owner

The record button held four things: the gesture, the state of the recording, the
capture engine, and the decision of what to do with the result. The engine was a
thread-static singleton every loaded button subscribed to, so a recording started
in one chat drove the state of every other chat and story composer on the thread,
and QuantumProcessed was a single field that whichever button loaded last took
over and the first to unload set back to null.

ChatRecordSession now owns the state and the engine, one per button, which is one
per chat. What is left in the button is the press-and-hold gesture and its own
visuals.

Seven booleans and an integer interface state become three named states. The
fourth one - locked, then stopped - was only reachable through StopRecording(false),
which nothing ever called, so it went out along with the tri-state stop that
neither sent nor discarded what it recorded. Cancel and Complete say which they
are.

Elapsed comes off a monotonic clock rather than DateTime.Now, freezes while
paused, and starts when the capture device is actually open rather than when the
button was pressed. The pause state is reset when a recording ends instead of
leaking into the next one, and the bar detaches from the button on unload.

Permissions go through MediaDevicePermissions, which is what calls already use,
so granting access no longer costs the first press: the old check asked
DeviceAccessInformation and then returned false regardless, leaving the prompt as
the only thing that press did.

MediaCapture.Failed ends the recording instead of only logging it, and a press
too short to record now says so.

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

#unigram