Fix import library not being copied on a clean first build (#1017)

* Fix import library not being copied on a clean first build

libHttpClient.import.props staged its build output into consuming projects
using a static ItemGroup:

    <ItemGroup Label="CopyDependencies">
      <ReferenceCopyLocalPaths Include="$(HCOutDir)\*" />
    </ItemGroup>

Static item globs are expanded during project evaluation, which happens
before the referenced libHttpClient project has been built. On a clean tree
$(HCOutDir) does not exist yet, so the glob matches nothing and no output is
staged. A second build appears to fix it only because the folder has been
populated in the meantime.

Move the glob into a target so expansion is deferred to execution time,
after ResolveProjectReferences has built the referenced project.

Observed on a clean tree (Debug|Gaming.Desktop.x64, GDK 260403, v143),
consuming project output folder:

    before fix, build 1:  libHttpClient.GDK.dll only (no .lib/.exp/.pdb)
    before fix, build 2:  dll + lib + exp + pdb      (1.0s, pure copy)
    after  fix, build 1:  dll + lib + exp + pdb

Consumers that link against the staged output fail with
LNK1181: cannot open input file 'libHttpClient.GDK.lib' until a second
build is run.

On the GDK this had a second effect worth calling out: because nothing was
staged from $(HCOutDir), the DLL that landed next to the consumer on build 1
was not the source-built one at all. It was the deprecated GDK extension
library redist, arriving via a different path. Verified by hash:

    consumer output   9D6FB197238977FFF70F33F064DCF8A8E4BD79BDA32F2352534965BE14784551
    GDK ext redist    9D6FB197238977FFF70F33F064DCF8A8E4BD79BDA32F2352534965BE14784551
    source-built DLL  7AD26FAD7CDD2F01157E5E12D61F60344D81B577684864001C44A1F0A98E0686

So a clean first build produced a mismatched pair: an extension-library DLL
with no import library. After the fix the consumer receives the source-built
DLL and its matching import library. This matters ahead of GDK 2610, which
removes the extension library paths entirely.

Also replaces the stale "Copy PlayFabCore to OutDir" comment, which did not
describe what this block does.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: bdd5537e-42e5-4d3b-bf94-d1218cd0610e

* Clarify staging comment to cover the static-library configuration

The comment described the staged output as dll, import library, pdb, which
is only true for the dynamic flavor. When HCStaticLib=true the target stages a
static library and its pdb instead, with no DLL or import library.

Verified by clean builds of both flavors (Debug|x64, v143):
  dynamic: libHttpClient.Win32.dll/.exp/.lib/.pdb
  static : libHttpClient.143.Win32.C.lib/.pdb

Comment-only change; no behavior change.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: bdd5537e-42e5-4d3b-bf94-d1218cd0610e

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: bdd5537e-42e5-4d3b-bf94-d1218cd0610e

Author: amccalib

Build/libHttpClient.import.props

@@ -71,9 +71,28 @@
     </Link>
   </ItemDefinitionGroup>
 
-  <!--Copy PlayFabCore to OutDir-->
-  <ItemGroup Label="CopyDependencies">
-    <ReferenceCopyLocalPaths Include="$(HCOutDir)\*" />
-  </ItemGroup>
+  <!--
+    Copy libHttpClient's build output next to the consuming project. What that output is depends
+    on the configuration: the dynamic flavor produces a dll, import library and pdb, while
+    HCStaticLib=true produces a static library and its pdb. The glob below stages whichever
+    applies.
+
+    This must be populated from inside a target rather than from a static ItemGroup. Static item
+    globs are expanded when the project is evaluated, which happens before the referenced
+    libHttpClient project has been built. On a clean tree $(HCOutDir) does not exist yet, so an
+    evaluation-time glob matches nothing and nothing is staged at all. Consumers that link
+    against the staged output then fail with:
+
+        LNK1181: cannot open input file 'libHttpClient.GDK.lib'
+
+    A second build appears to fix it only because the folder is populated by then. Running the
+    glob inside a target defers expansion to execution time, after the project reference has
+    been resolved and built, so a clean first build stages the correct files.
+  -->
+  <Target Name="HCCopyDependencies" AfterTargets="ResolveProjectReferences">
+    <ItemGroup>
+      <ReferenceCopyLocalPaths Include="$(HCOutDir)*" />
+    </ItemGroup>
+  </Target>
 
 </Project>