feat: replace EOL netcoreapp3.1 target with net8.0

[tanderson-ld]

Summary

LaunchDarkly.Logging 2.0.0 still ships a netcoreapp3.1 target. Under NuGet's nearest-compatible asset selection, every .NET 5+ application (including net8.0 services and MAUI net8.0-* apps) selects that asset, so an assembly built against EOL .NET Core 3.1 lands in modern applications. Security scanners flag the EOL runtime references, and this has been reported through customer support as failing CI/CD security gates.

This PR replaces the netcoreapp3.1 target with net8.0, matching the rest of the SDK family (ServerSdk since 8.9.0, CommonSdk since 7.0.1, InternalSdk since 3.8.0). No code changes are required: Logs.CoreLogging is gated on #if NETCOREAPP, which is also defined for net8.0. Per review, the Microsoft.Extensions.Logging.Abstractions floor on the net8.0 target moves to 8.0.3, the framework-matched band.

Related ticket: SDK-3131

Consumer impact

Consumer	Asset before	Asset after	Effect
net8.0+ / net10 / MAUI	netcoreapp3.1	net8.0	same API; Microsoft.Extensions.Logging.Abstractions floor moves 6.0.0 → 8.0.3; scanner finding resolved
.NET Framework 4.6.2+	net462	net462	none
netstandard2.x libraries	netstandard2.0	netstandard2.0	none
netcoreapp3.1, net5–net7 (all EOL)	netcoreapp3.1	netstandard2.0	all APIs available except Logs.CoreLogging; the LaunchDarkly.Logging.Microsoft package provides the equivalent adapter there

Shipped as feat: (2.1.0), consistent with how the equivalent target-framework changes shipped across the SDK family. (2.0.0 was a major because dropping net452 made the package uninstallable for .NET Framework < 4.6.2; this change leaves every current consumer installable and functional.)

Notes for reviewers

• Release prerequisite: fix: add release-please version markers to csproj #21 (release-please version markers in the csproj) should land before cutting the release, or release-please will publish with a stale <Version> stamp.
• Optional variant: adding a net10.0 target alongside net8.0 is a one-line change that would pre-empt the same scanner issue recurring when net8 reaches EOL (November 2026). Left out here to match current family convention — happy to add if preferred.
• Follow-up (separate PRs, dotnet-core): raise the LaunchDarkly.Logging floor in ServerSdk and ClientSdk so customers pick this up transitively; NuGet's lowest-wins resolution means nothing changes for them until then. Customers can opt in immediately with a direct PackageReference.

Testing

• dotnet build (0 warnings) and dotnet test (52/52 passed) locally on net8.0/netstandard2.0, including NetCoreLoggingTest exercising Logs.CoreLogging against the retargeted asset.
• CI matrix (SDK 8.x/9.x on ubuntu + windows) builds all three targets including net462.

---

Note

Overview
Replaces the EOL netcoreapp3.1 NuGet target with net8.0 so modern .NET apps stop resolving the 3.1 asset (and related scanner failures) while keeping net462 and netstandard2.0.

The net8.0 build now references Microsoft.Extensions.Logging.Abstractions 8.0.3 (was 6.0.0 on 3.1); tests use Microsoft.Extensions.Logging 8.0.1. Logs.CoreLogging stays behind #if NETCOREAPP—only XML/docs and README/CONTRIBUTING examples are updated to describe .NET 8.0+.

^{Reviewed by Cursor Bugbot for commit bb92882. Bugbot is set up for automated code reviews on this repo. Configure here.}