windows: downstream hosts re-list rivet runtime sources by hand — the list rots (podlens LNK2001 case) #280

What happened

PodLens pins rivet at c7f9881 (post-#271) and its Windows host failed to link:

protocol.obj : error LNK2001: unresolved external symbol "bool __cdecl rivet::detail::valid_utf8(unsigned char const *,unsigned __int64)"

Root cause: runtime/src/protocol.cpp now uses valid_utf8 (defined in the newer runtime/src/utf8.cpp), but PodLens's committed windows/RivetHost.vcxproj still vendored the old four-file list (backend.cpp, win32_pipe_transport.cpp, system_services.cpp, protocol.cpp). The canonical list lives only in rivet's own platform/windows/rivet-host.vcxproj (15 ClCompile entries today, vs runtime/CMakeLists.txt's 8 runtime units), and nothing tells downstream hosts when it grows.

Why this will recur

Every new runtime translation unit (there have been three recently: utf8.cpp, x509_spki.cpp, discovery_advertisement.cpp) silently breaks every Windows host that compiles rivet sources into its own vcxproj. The Linux side has the same shape (hosts mirror platform/linux/rivet_linux_sources.cmake), but at least that file is a single include-able artifact; Windows hosts hand-copy <ClCompile> lines.

Proposal

Make the Windows source list machine-consumable so downstream lists can't rot, aligned with #238's packaged-consumption direction:

1. Ship a platform/windows/rivet-runtime-sources.props (or .targets) defining the authoritative ClCompile set, and have rivet-host.vcxproj import it — so rivet's own build and the published artifact can never disagree.
2. Document in the platform README that Windows hosts must import the props instead of re-listing sources (same contract as the Linux cmake file).

Until #238 lands prebuilt static libs, this keeps vendored lists from diverging. Happy to send the PR if the shape sounds right.