Remove Go 1.26 Windows c-shared linker workaround once golang/go#78238 is fixed

[manusa]

Context

Go 1.26 (introduced via #391) regressed -buildmode=c-shared for windows/amd64 when the output filename contains dots (e.g. helm-windows-4.0-amd64.dll). The new peCreateExportFile in cmd/link/internal/ld/pe.go emits a LIBRARY directive in the generated export_file.def using filepath.Base(outopt) verbatim, which GNU ld (mingw-w64 binutils) rejects with:

```
ld.exe: export_file.def:1: syntax error
ld.exe: export_file.def: file format not recognized; treating as linker script
```

Upstream tracker: golang/go#78238 — open, fix milestone Go 1.27, no backport to 1.26.x announced.

Workaround in this repo

We pass -extldflags '-Wl,--export-all-symbols' to the Go linker for Windows targets only. That short-circuits peCreateExportFile entirely (see the slices.Contains(flagExtldflags, ...) guard in pe.go), so the broken .def is never generated. Side effect: the DLL re-exports all Go symbols rather than just the //export-marked ones — same behavior as Go 1.25 had by default, fine for our JNA consumers.

Applied in:

• Makefile — build-native target (native Windows build)
• Makefile — build-native-cross-platform target (xgo cross-build, Windows targets only)

Removal criteria

Remove the workaround when either:

• Go 1.26.x ships with cmd/link: peCreateExportFile generates invalid .def file when output name has trailing dot (c-shared on Windows) golang/go#78238 backported, or
• We've bumped the toolchain to Go 1.27+ (where the fix lands)

At that point, drop the --export-all-symbols ldflags additions and re-merge the xgo invocation into a single call.

[manusa]

Closing — the underlying Go 1.26 bump (#391) was reverted to Go 1.25.10 because the proposed --export-all-symbols workaround turned out to be infeasible: it bypasses peCreateExportFile as expected, but the resulting build then exceeds PE's 16-bit export ordinal cap (~107k symbols vs. 65k limit).

The Go 1.26.x bump is now folded into #393's scope: once xgo is removed and the Windows DLL gets a clean filename, the golang/go#78238 trigger goes away on its own.