Six memory flags are inert for the intrinsic arms

[12yuens2]

Found while planning #9 (Phase 6).

--successful_topk, --failed_topk, --insights_topk, --threshold, --hop and --use_projector all feed the retrieval path. The five intrinsicmemory-* modules do not override retrieve_memory, so it returns [], [], [] from MASMemoryBase and none of the six changes anything.

Sweeping over any of them with --mas_memory intrinsicmemory-* therefore produces identical arms under different filenames — no error, no warning, and the flag values are not in the result rows either, so two such runs are indistinguishable after the fact.

--use_projector is a subset of this and was already known: only g-memory implements projection.

Options, roughly in order of effort:

• document it in the README flag table (one column: which modules read the flag)
• refuse the combination at parse time, the way an unknown --mas_memory is refused
• put the flags that a run actually varied into the identity columns, so two arms cannot share a key — this is what use_validator and now intrinsic_cross_task do

Related: #9 gives the intrinsic family a cross-task setting, and whether any of these six become live for it depends on the store-and-retrieve decision in the sibling issue.

[12yuens2]

Triage against the submitted sweep, so this is not read as urgent: slurm/generate_slurm.py passes none of the six flags, so every arm of the 2026-09-04 run takes their defaults and no two arms differ only by an inert one. The failure mode is available, not active — nothing in the results is currently indistinguishable for this reason.

Of the three options, the second is the one that makes it structurally impossible rather than documented: refuse the combination at parse time the way an unregistered --mas_memory is refused. That needs a declared per-module set of flags read, which the registry can carry — and the same declaration is what the README column in option 1 would have to be generated from anyway, so it subsumes it.