Restore windows/amd64 build target and fix .exe suffix in relink

[norman-abramovitz]

windows/amd64 was a first-class build target until the gox-based ship path was
replaced by the Makefile-based multi-platform build. It was dropped as a side
effect of that migration, not by decision — the old path still exists as dead
code:

# ci/scripts/shipit:41 — referenced by nothing today
TARGETS=${TARGETS:-linux/amd64 darwin/amd64 windows/amd64}

The replacement defined TARGETS fresh as four linux/darwin entries. The net
trade was unintentional: the old path had windows but no arm64; the new path
added arm64 and lost windows.

Restoring it needs three defects fixed, or the restored target ships broken
artifacts.

1. relink omits the .exe suffix — the blocking one

The two build paths disagree:

# Makefile:193 — release-workdir, feeds prereleases. go build appends .exe itself
go build -work -ldflags="$(GO_LDFLAGS)" -o $$outdir/ ./cmd/$$cmd/...   → scheduler.exe

# Makefile:250 — relink, feeds final releases. Explicit -o, no suffix
go tool link ... -o $$outdir/$$cmd $$main_a                            → scheduler

With GOOS=windows, prereleases would contain scheduler.exe and final
releases an unrunnable scheduler. Both tarballs look well-formed, so this
fails silently.

This is the same divergent-ship-path shape as the toolchain issue fixed in #20 —
the two paths do not exercise the same machinery, so a defect can live in one
unnoticed.

2. TARGETS is defined twice, and the second is dead

Lines 10–13 and 91–94 duplicate MODULE, CGO_ENABLED, TARGETS and
TESTFILES. Both use ?=, so line 93 never takes effect — line 10 has already
set the variable.

Editing line 93 to add a platform produces no change at all. That is a silent
trap for anyone modifying the build matrix. Remove the duplicate block.

3. clean leaves Windows binaries behind

# Makefile:144
@rm -f ./tzlist ./scheduler

Pipeline side

In the current shape, a windows target also needs a build-windows-amd64 S3
resource, its put in build, a get in ship-prerelease, and an entry in
the ci/scripts/release prerelease loop.

If the S3 resource consolidation lands first, everything flows through
build-workdir and only the TARGETS line changes.

Acceptance criteria

• windows/amd64 present in TARGETS; duplicate block removed
• relink emits scheduler.exe / tzlist.exe for GOOS=windows
• Prerelease and final-release tarballs contain identically-named binaries
• clean removes .exe artifacts
• A published release carries ocf-scheduler-windows-amd64-<version>.tar.gz

Motivation

ocf-scheduler is also pushable as a plain CF app and should run on every
available CF stack, Windows stacks included.