Add Copilot instructions for PR review

[kandrosov]

Why

This repository had no copilot-instructions.md, so Copilot reviewed its PRs with no idea what
this code is for or what goes wrong in it.

The file added here is written for PR review, not onboarding — the five existing files in the
ecosystem were generated by Copilot's repository-onboarding feature in November 2025, and are
being rewritten in the same way (cms-flaf/FLAF#310 and its companions): what a useful comment
looks like here, the invariants worth checking with the failure signature each produces, the rule
that documentation ships in the same PR, and — deliberately — what not to comment on, since
noise is an automated reviewer's main cost.

Framework-wide rules are not duplicated; the file points at FLAF/.github/copilot-instructions.md
for them.

Testing

Documentation only — no code change. Every path, filename and directory referenced was verified to
exist in the current tree, and the facts table is dated so the next reader knows how much to trust
it.

What it says

This repository has no CI at all — no formatting check, no consistency check, no integration
test. Review is the only gate between a change here and a production that runs for days on the
grid, and nothing in it executes at review time, so nothing fails fast. The file opens with that,
and asks reviewers to read a diff the way they would read a configuration change to a running
system: assume it will be applied exactly as written, and ask what it will produce.

Specifics:

• Numbers must be derivable. The setups carry events_total per era, and the existing files
  write out how those numbers were obtained — a luminosity scaling from central production, then a
  unification rule across mass points. A diff that changes a count, adds an era or adds a mass
  point must keep that derivation truthful; a number that no longer follows from the comment above
  it is the most expensive error this repository can hold (too low and the sample is unusable, too
  high and the grid time is wasted).
• A card change invalidates what already exists. Editing cards/ or fragments/ changes what
  a new gridpack produces while gridpacks already built stay as they were — silent divergence
  that is undetectable downstream.
• Names are an interface. Points name a production mode and final state with the tokens the
  central dataset uses on DAS, and the plugin maps those onto a cards directory and a fragment; a
  rename or a missing PRODUCTION_MODES entry breaks it at production time.
• Era coverage must agree between eras, nano_versions and DSProd's conditions — and Summer24
  MC is shared across 2024/2025/2026, so a count for 2024 covers all three.
• Never commit a gridpack or other large binary; those live in cms-flaf/DSProdGridpacks.

The "do not flag" list matters here too: generator card formats are MadGraph's, the verbose
comment blocks are the derivation record rather than clutter, and nothing is testable in
isolation.

Branched from main and developed in a worktree, so the add-2022-eras work in progress is
untouched.