UnigramDev/Unigram/develop • 5082051 • 1 files, +39/-4
crash-triage: make the app log tail a first-class diagnosis step

The log tail is the most useful part of a crash record and was only mentioned
as a flag. The stack says where the app died; the log tail says what it was
doing, which is usually what explains the crash.

Documents both halves: the state header (memory used/available, window size,
scaling, active calls, raw HRESULT) which is worth checking against the crash's
device spread, and the timestamped [File.cs:line][Method] trace, which carries
its own source locations and so corroborates the symbolicated stack
independently.

Diagnosis now requires reconciling stack, log tail and source at the reference
commit, rather than reasoning from the stack alone. Also notes that app logging
is currently sparse, so a missing log line is a legitimate follow-up to raise
in the PR.

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

UnigramDev/Unigram/develop • d36dec9 • 2 files, +48/-0
Handle clicks in gallery

UnigramDev/Unigram/develop • cfff648 • 11 files, +305/-23
Extend the orphan analysis to the gallery and mini apps

Analyze reports whatever is registered but unreachable from the roots it is
given, so it only works as a single call over the union of every area's roots:
running it per area marks every other area's live objects as leaked. ChatView
therefore stops calling it and exposes DebugRoots instead, MainPage assembles
the union, and each area contributes roots and a descent that return nothing for
types they do not own.

The gallery registers what a leak there actually costs: the window, its content
and transport controls, the compact overlay that outlives it on purpose, and the
player base, whose decoder and surfaces are the reason any of this matters. The
window stops being a root once nothing legitimately holds it, so anything still
referencing it past that point is the leak rather than the owner.

WebAppPage joins the same analysis, and its event subscriptions move with it.
Both constructors subscribed Window.Current.Activated, CloseRequested,
Consolidated and VisibleBoundsChanged, and neither unsubscribed, so the page
stayed reachable from the view for as long as the view lived. They now hook and
unhook in the UserControlEx OnLoaded and OnUnloaded pair, which is guaranteed to
alternate; the raw Loaded and Unloaded events fire again on every reparenting,
and CloseRequested and Consolidated take deferrals, so a second handler would
mean a second confirmation dialog rather than merely wasted work.

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

UnigramDev/Unigram/develop • b239b87 • 15 files, +154/-159
Code cleanup

UnigramDev/Unigram/develop • eb9411e • 7 files, +264/-15979
Improve rich editor

UnigramDev/Unigram/develop • bf24e59 • 2 files, +129/-13
Add buttons support in rich messages

#unigram