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>

Author: FrayxRulez

Directory.Build.props

@@ -2,9 +2,11 @@
 
   <PropertyGroup>
     <UnigramRoot>$(MSBuildThisFileDirectory)</UnigramRoot>
-    <!-- Only these three consume vcpkg: the two native components link against it, and the app
-         needs the runtime DLLs in its output and its package. -->
-    <UnigramUsesVcpkg Condition="'$(MSBuildProjectName)' == 'Telegram.Native' Or '$(MSBuildProjectName)' == 'Telegram.Native.Calls' Or '$(MSBuildProjectName)' == 'Telegram'">true</UnigramUsesVcpkg>
+    <!-- Only these consume vcpkg: the two native components link against it, and the app needs
+         the runtime DLLs in its output and its package - both builds of it, since Telegram.Modern
+         packages the same dependencies. Without it there libvlc loads and then dies, its plugins
+         never having been copied. -->
+    <UnigramUsesVcpkg Condition="'$(MSBuildProjectName)' == 'Telegram.Native' Or '$(MSBuildProjectName)' == 'Telegram.Native.Calls' Or '$(MSBuildProjectName)' == 'Telegram' Or '$(MSBuildProjectName)' == 'Telegram.Modern'">true</UnigramUsesVcpkg>
   </PropertyGroup>
 
   <!-- Where vcpkg lives, in order of preference: an explicit override, the VCPKG_ROOT variable,

Telegram/Telegram.Modern.csproj

@@ -215,11 +215,11 @@
        Telegram.Native has to have been built by the solution first. Calls only adds its own two
        files; the rest of its folder is the same ffmpeg set. -->
   <ItemGroup>
-    <!-- zlib1 and Win2D also arrive with tdjson and from the Win2D package respectively. The
-         legacy build copies both copies over each other and lets the last one win; publish here
-         calls that NETSDK1152, so the native folder's are the ones dropped. -->
-    <ReferenceCopyLocalPaths Include="..\$(Platform)\$(Configuration)\Telegram.Native\*.dll"
-                             Exclude="..\$(Platform)\$(Configuration)\Telegram.Native\zlib1.dll;..\$(Platform)\$(Configuration)\Telegram.Native\Microsoft.Graphics.Canvas.dll" />
+    <!-- Only the components themselves. Their folders also hold the whole ffmpeg/libvlc set, but
+         those come from vcpkg through Directory.Build.targets, as they do for Telegram.csproj -
+         copying both is NETSDK1152, sixteen files deep. Same for Win2D, which comes from its
+         package, and Telegram.Td.dll, which the shipping package does not carry at all. -->
+    <ReferenceCopyLocalPaths Include="..\$(Platform)\$(Configuration)\Telegram.Native\Telegram.Native.dll" />
     <ReferenceCopyLocalPaths Include="..\$(Platform)\$(Configuration)\Telegram.Native\Telegram.Native.pri" />
     <ReferenceCopyLocalPaths Include="..\$(Platform)\$(Configuration)\Telegram.Native.Calls\Telegram.Native.Calls.dll" />
     <ReferenceCopyLocalPaths Include="..\$(Platform)\$(Configuration)\Telegram.Native.Calls\Telegram.Native.Calls.pri" />

net10-port-todo.md

@@ -287,6 +287,14 @@ Two more things the packaging path needed:
   build copies both over each other, publish calls it `NETSDK1152`.
 - **The downloaded tdjson binaries carry the mark of the web**, which the PRI step refuses
   (`MSB3821`). `Unblock-File` on `Libraries\tdjson\x64\tdjson.dll` and `.pdb` clears it.
+- **`UnigramUsesVcpkg` matches on project name**, so `Telegram.Modern` was invisible to it and got
+  neither the vcpkg runtime DLLs nor libvlc's plugin tree — video died natively, with no managed
+  error report to show for it, because libvlc loads and then finds no plugins. The project is now
+  in that list in `Directory.Build.props`, which also means the plugins keep their
+  `plugins\<category>\<name>.dll` shape, as `plugins.dat` records those paths.
+  Consequence: the vcpkg runtime DLLs then collide with the same sixteen ffmpeg/libvlc files if
+  they are also copied out of `x64\Release\Telegram.Native\`. Only the components themselves come
+  from there now; the shared set comes from vcpkg, exactly as for `Telegram.csproj`.
 - **`Content` needs `CopyToOutputDirectory`.** The legacy UWP project system deployed `Content`
   implicitly; SDK-style does not, and nothing says so at build time. The app started, initialised
   TDLib, wrote its databases — and then died on