Add copyright header to make.bat

[caglarpir]

Summary

Meta's Open Source Automated Checkup flags this repository for the Copyright Headers requirement. make.bat is the only scanned source file in the repo missing a copyright header — every other file already carries one, and the remaining files are either binary or covered by the checkup's global extension/path exemptions.

This adds the standard Meta OSS MIT header to make.bat using batch-file comment syntax (@REM), placed above @echo off so it stays within the first 16 lines that the checker inspects.

Test plan

Comment-only change; no functional impact. make.bat behaviour is unchanged — @REM lines are batch comments and the leading @ keeps them from being echoed.

[caglarpir]

Heads up on the red build check — it is pre-existing CI breakage, unrelated to this PR.

Where it fails: the Install dependencies step of the PyTest workflow (make setup-dev → pipenv install --dev).

Root cause:

1. .github/workflows/pytest.yml pins python-version: "3.x", which currently resolves to CPython 3.14.7.
2. Pipfile.lock pins scipy==1.15.3, which publishes no cp314 wheels — so pip falls back to building it from the sdist.
3. Building scipy from source needs BLAS, which the ubuntu-latest image does not provide:

Run-time dependency scipy-openblas found: NO  (tried pkg-config)
Run-time dependency openblas found: NO  (tried pkg-config and cmake)
../scipy/meson.build:274:9: ERROR: Dependency "OpenBLAS" not found (tried pkg-config and cmake)

4. → make: *** [Makefile:42: setup-dev] Error 1

Why this PR is not implicated: the change adds a comment to make.bat, a Windows batch file. CI runs on ubuntu-latest and invokes make setup-dev, which reads Makefile — make.bat is never executed in the pipeline, and the diff is comment-only in any case.

The last successful run of this workflow on main was 2025-07-21 (Release 1.0.15). In the intervening time Python advanced to 3.14 while the lockfile stayed frozen, so any PR opened against this repo today fails the same way.

Fixing it is a separate concern from this copyright-header change, so I have deliberately left it out of scope. The minimal repair would be pinning python-version to a version the lockfile supports (e.g. "3.12"); a fuller fix would regenerate Pipfile.lock. Happy to open a separate PR for that if it would be useful.