ACQ_ScanPipeJobSettings: STORE_discard and nStoredScans are still unmodelled (spec 3.3, 13.1) #170

From §6.2 of the format-conformance review against
FILE_FORMAT.md.

The gap

§13.1 makes ACQ_ScanPipeJobSettings[j] the companion of ACQ_jobs[j]: a
17-element struct whose first fields are
(storeDataMode, storageDataType, displayMode, logTimeStamp, accumMode, …).
#165 reads storageDataType (so a STORE_64bit_float job is no longer read as
int32). Two members remain unmodelled:

• storeDataMode = STORE_discard — "data is not written at all, so no
  rawdata.<title> file exists for that job". Job enumeration does not know
  this, so a discarded job looks like a missing file rather than an expected
  absence.
• nStoredScans — §3.3 states that
  ACQ_ScanPipeJobSettings[n].nStoredScans is the field defined to correspond
  to the file size, while ACQ_jobs[n].nStoredScans is what the reader uses.
  The two agree throughout the review corpus, so this is a latent divergence:
  when they disagree — an aborted scan is the documented case — the file size
  follows the settings field and the reader would size the array from the other
  one.

Proposal

1. When enumerating raw-data jobs (Study.get_dataset, Folder discovery),
   skip jobs whose storeDataMode is STORE_discard instead of treating the
   absent file as an error.
2. Cross-check the two nStoredScans when both are present, prefer
   ACQ_ScanPipeJobSettings[n].nStoredScans for sizing (it is the one defined
   against the file), and warn on disagreement — the disagreement is the useful
   signal for an aborted scan.
3. Cover the §3.3 per-job receiver count while in there:
   ACQ_ReceiverSelectPerChan[chanNum-1] agrees with the global
   PVM_EncNReceivers shortcut in 67/67 corpus jobs, so reading it is cheap
   insurance rather than a change in behaviour.

A synthetic acqp is enough to test all three; the corpus has no dataset that
exercises them.