[find-ui] Allow users to retrieve untruncated, paste-ready samples with --id

[chiaramooney]

Summary

winapp find-ui --id <id> does not always return a complete, paste-ready/buildable sample. Some results contain an explicit <!-- ...truncated --> marker, including toolkit-tabbedcommandbar-1, gallery-gridview-2, and toolkit-gridsplitter-1.

Reproduction

winapp find-ui --id toolkit-tabbedcommandbar-1

The returned XAML ends early and contains:

<!-- ...truncated -->

Question / proposed direction

Do we need an option that lets users request the full, untruncated snippet? For example, --full, --no-truncate, or another explicit mode could preserve concise default output while allowing users and agents to retrieve complete code.

Whichever behavior we choose, the command should make clear whether the result is intended to be directly buildable. If full source cannot be returned, it should provide a source URL or another deterministic way to retrieve it.

Expected behavior

Users and agents should have a documented way to retrieve a complete sample, including required XAML/C# and prerequisite notes, without silently receiving incomplete code.

[Jaylyn-Barbee]

Reviewed — this is a real gap, but the fix is a product/UX decision rather than a quick bug fix, so flagging the constraints before we pick a direction.

Why it's not a one-liner: the full source isn't retained locally. Truncation happens at fetch time, not render time. GalleryFetcher/ToolkitFetcher truncate the XAML/C# (ControlSnippetText.TruncateXaml / TruncateCode) before writing scenarios.json, so the per-user cache only ever holds the truncated snippet. A --full / --no-truncate flag therefore can't just "print more" — there's nothing longer on disk to print. The truncation exists on purpose: it keeps --id output within a sane token budget for agents and trims deeply-nested Gallery samples.

Options, roughly in order of effort:

1. On-demand full fetch for --full. --id <id> --full re-fetches that one sample's upstream file and emits it untruncated. Feasible per-id for Gallery/Toolkit (we already know the upstream path), needs network, and should stay opt-in so the default remains concise. This is my recommended primary direction.
2. Deterministic source pointer. When a result is truncated, include the upstream sample URL in the output (and in the --json payload) so a human/agent can retrieve the complete file. Cheaper than (1) and directly answers "if full source cannot be returned, provide a source URL." Good to ship alongside (1) regardless.
3. Raise/annotate the truncation limits. Tune MaxXamlChars/MaxCSharpChars, or make the <!-- ...truncated --> marker explicit that the snippet is intentionally clipped and how to get the rest. Smallest change, doesn't fully solve "buildable."

Note: even a full fetch doesn't guarantee a buildable file — Gallery keeps event handlers in shared page code-behind we don't fetch (see the dangling-handler work in #681, and the upstream-index discussion in #703). So "complete sample" and "drop-in buildable" are related but not identical goals; #703/#704 are the durable fix for the latter.

Leaving open pending a call on (1)+(2) vs (3). If we agree on (1)+(2) I'm happy to implement it as a follow-up. Not bundling it into #681, which is already scoped.