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

A production runs for days across many sites and yields samples analyses then trust, so the
expensive failures are the ones that finish successfully with the wrong content — wrong global
tag, wrong event count, a step run with a mismatched release. Nothing downstream notices: the
files are valid, they are simply not what was asked for. The file asks reviewers to weigh a diff
by what it would cost to discover the mistake after the samples exist.

Specifics:

• Conditions (config/conditions_Run3.yaml) pin what every subsequent sample is produced
  with; the conditions-check workflow also runs weekly because central campaigns get amended
  after they open. A value copied from another era must be deliberate.
• The gridpack store must never be checked out normally. gridpacks is a Git-LFS store meant
  to be checked out sparsely with LFS downloads disabled by setup_gridpacks.sh; a plain
  recursive git submodule update --init pulls ~610 MB. Any script, workflow or docs snippet that
  adds it to a recursive update is a finding.
• Step chaining (dsprod/run_step.py): each step's release and conditions must match the
  setup, output filenames must thread through, and event counts should not change across the chain
  without a filter to explain it.
• The job and storage machinery mirrors FLAF's, so the FLAF invariants apply — completeness
  decided by remote paths, cached exists(), read-after-write lag.
• Registry and setup entries must be added in step, or a process fails only when someone produces
  it.

Documentation: this repository has its own MkDocs site, so the docs gate points at the specific
pages (configuration/conditions.md, configuration/prod-setups.md, configuration/processes.md)
and at mkdocs build --strict. A change to what cms-flaf/DSProdModels must provide needs a PR
there too.

Branched from main and developed in a worktree, so the fix-nano-merge-haddnano work in progress
is untouched.