feat(detector): Bosch EDC16CP31 (Mercedes OM642/OM646) family

[COSSART-FR]

What this adds

Support for the Bosch EDC16CP31, the common-rail ECU of the Mercedes CDI
engines (OM642 V6, OM646 4-cyl). Follows the layout described in
CONTRIBUTING.md: new detector module, strict identifier, routing, frontend
declaration.

Calibrated and verified on a real OM642 dump (CLK 320 CDI W209, Daimler
project CR4-642, SW 1037393817, 2 MB). No dump is committed — the tests that
need one read it from ZEDSUITE_CP31_DUMP and are #[ignore]d otherwise.

Detection engine (Rust)

• detector/ecu/bosch/edc16cp31/ — EDC16CP31Detector with
  signatures.rs. 16 families (14 maps + 2 curves): rail pressure
  set-point and limiter, boost set-point and limiters, smoke limiter,
  thermal quantity limiter, quantity limit by boost and by rpm, driver wish
  ×2, torque→quantity, main-injection timing, air-mass set-point, boost
  controller base duty.
• The CP31 stores its calibration as self-describing blocks
  (Kf_Xs16_Ys16_Ws16: nx, ny, X[], Y[], Z[] column-major;
  Kl_Xs16_Ws16 for curves). The detector reads them instead of assuming
  dimensions, so a 12×12 map in a 16×16 allocation is read correctly.
• Families are located by exact axis key ([nx][ny] + X + Y, byte for
  byte), independent of address. A map whose Z values were remapped is still
  found, and a software not in the corpus can still yield maps. Byte
  markers and a bounded zone sweep are the fallbacks, in that order. Curves
  are keyed only — a blind sweep would match any increasing vector.
• Big-endian (MPC5xx) throughout.

Identifier

ecu_identifier.rs: positive evidence only — Bosch software number at the
calibration start (positional, not a substring search), Daimler engine tag,
Daimler part-number format. A VAG part number vetoes the Mercedes gate.
Tests include foreign_2mb_file_is_not_cp31 and
cp31_dump_is_never_labelled_vag.

Frontend (TypeScript)

• ecus.json, SUPPORTED_ECUS, ECU list, i18n strings.
• EDC16 checksum: the region end is now only required to be
  dword-aligned. The 0x100 end alignment was a property of the six VAG pairs
  in the original corpus, not of the format — the CP31 region is
  0x190000..0x1FCFFB and was rejected as "unsupported checksum" although
  its sum is exactly reproducible. Start alignment (which constrains the
  signature position) is unchanged, and MIN_REGION_LENGTH compensates.
  The six VAG pairs still reproduce.
• Solution edc16cp31_egr_off: replayed from a verified stock/EGR-off
  pair (21 ranges, 60 bytes, all inside the EGR block). Anchored by
  signature with a guard on the original bytes; returns nothing on any
  mismatch, no hard-coded address.
• Power estimation: OM642 engine preset and a CP31-specific minimum AFR
  (the model has no torque limiter in Nm on this family, so treat CP31
  figures as an order of magnitude).

Docs

• docs/PORTING-EDC16CP31.md — how the port was done, reusable for other
  Kf/Kl-based EDC16 variants.
• docs/EDC16CP31-OM642-maps.md — reference sheet of the located maps
  (addresses on SW 1037393817, grids, factors, axes, pitfalls).

Validation

• cargo test green (52 tests added: identifier, block reader, every
  family, build_expected_report_edc16cp31 consistency).
• tsc --noEmit clean, tauri build OK on Windows x64.
• Real dumps imported in the app: stock, EGR-off, and a modified file all
  report the same 27 elements; 2 MB dumps of other ECUs are rejected.
• Rebased on 1.1.7. DETECTOR_VERSION bumped to 43 (39–42 were used by
  both this branch and 1.1.7, so every EDC15/CP31 project is re-scanned).

Known limits

• Corpus of one software (1037393817, OM642 165 kW). The OM646 4-cyl
  is declared but has not been verified on a dump.
• tuned_mode is never requested by the UI (the three detectMaps calls
  pass false); worked around for keyed families, not fixed at the root.
• FlMng_facFullLd_CUR deliberately not shipped: its declared
  COMPU_METHOD (1/128) contradicts the values found (up to 2.0).
• No TypeScript test runner in the project, so the EGR solution has no
  permanent test. Happy to add Vitest in a follow-up if you want it.

Unrelated: cargo clippy on 1.98 fails on three pre-existing
ifs_same_cond in edc15p/mod.rs (4048/4515, 4075/4539, 4340/5038). Not
touched here — I'll open a separate issue.

[Copilot]

The job was not started because the account is locked due to a billing issue.

[LeZed97]

Thanks for this, and for the care that went into it. I read the whole thing and ran it against my bench before answering: the detector and the identifier give byte-identical results to master on every VAG file I have (EDC15P, EDC15VM, EDC16), and the checksum still works exactly as before. So nothing in this PR hurts the existing families, cargo test and tsc are clean, and the way you read the self-describing Kf blocks is honestly better than what the VAG detectors have to do. The porting doc is the kind of thing I wish I had written myself.

I am not going to merge it yet though, and I want to explain why properly, because it is not about the code quality, it is about how I decide a detector is finished. New ECU families are the contribution I want the most, so it is worth being precise.

How the existing detectors were built

Every family in the app went through the same loop. I locate the maps by hand on real dumps with the references I have (WinOLS packs, damos/A2L when there is one, the reference tool's map lists), I extract the structural signatures that identify each family (dimension headers, axis markers and layouts, selector blocks, spacing between maps), then I run the detector on a bench of real files, stock AND tuned, and I compare its output file by file with the references until they match. Then I chase the false positives, category by category, until the output is quiet. A detector is not "done" when it finds the maps on the file it was written on; it is done when it behaves on files it has never seen.

Some numbers, so you see what "finished" means here:

EDC15 and EDC16 VAG: more than 350 dumps all families together, mostly stock, with a share of tuned files, some modified on purpose and some at random, to see how the detector behaves on files that are not stock. On EDC15P the completeness check is 35 rules per codeblock written from tuner knowledge, not from statistics on the files: one EGR map, one driver wish plus two start-quantity maps, one torque limiter, two idle maps, the six injector durations 00 to 05 always with their selector, ten SOI maps, and so on. Every codeblock of the bench is at 100 %, and the gaps against the reference tool are documented and deliberate (hidden families). On EDC16 (U1, U31, U34) the invariants come from experience with these engines: every VAG EDC16 has exactly six main durations 00 to 05 with their selector, every one has the gearbox torque limiter slot, the smoke limiters come by MAF/MAP/lambda, the driver wish is 12 to 16 rpm points by 8 or 9 pedal points with the ninth being kickdown. Those rules are what let the app say "this file has been modified" instead of counting whatever it found.
Marelli MJD6: this is the one I want you to look at. I have 23 files covering every MJD6 variant, the detector matches the reference lists on all of them, and the false positives were cut category by category against a factory damos as ground truth. And I still consider that detector about 70 % done, and I chose not to ship it in the app: I have a stack of stock dumps to run it on first, and only then does the refinement start (families with shared axes, the DTC side, the small partial dumps that needed special-casing I do not fully trust). Being at 100 % on the reference was not enough for me to expose it to users.
That is the bar. Not because I enjoy being strict, but because of what the app is for. ZedSuite is meant to stay simple to understand: you open a dump, you get a short list of maps with a clear name, the right axes and the right units, and you can trust it. The whole value is in that trust. A false positive, or a real map with a wrong axis or a wrong factor, does the exact opposite of what the app promises: the user edits a "boost map" that is a diagnostic table, or reads mbar where the axis is mg, flashes it, and the app is the one that lied to them. One bad experience like that and the tool gets the reputation of being unreliable, which is worse than not supporting the family at all. So I would rather show fewer maps that are right than more maps that are almost right, and every family in the app is held to that.

Where the CP31 stands against that bar

It is calibrated on one dump, one software, one engine. Every axis key is the axis vector of that file, so on another software the key phase finds nothing and the detector falls back to the zone walk, whose false-positive rate nobody has measured yet. And this ECU is not an OM642 ECU: the same CP31 sits on the 4-cylinder OM646 of the same years with a different calibration, and the app works per ECU type, not per engine, exactly like a VAG EDC16 that serves a 1.9, a 2.0 and a 2.5 TDI. A CP31 detector has to behave on every engine the CP31 was fitted to; today the OM646 is declared but was never seen. There are no invariants yet, only "at least one of each family", because with one file you cannot know what a CP31 always carries. I have no Mercedes dump at all, so I cannot even run the bench myself. And the EGR OFF solution replays a tune from that same single file; beyond that, I am not integrating solutions of that kind for now, for several reasons I would rather not go into here. We can maybe talk about it in the future, but that part I will not take regardless of the corpus.

What would get this merged

A corpus. For a family like this I want in the range of 50 files minimum, stock and tuned, across the software versions and the engines this ECU is fitted to, OM642 and OM646 at least, power levels and years. Mercedes dumps are less common than VAG ones, so if you get to 30 real files with both engines represented, talk to me. Forum threads and the usual sources have them; people will also send files once the family is announced as being worked on.
A bench script like the ones I use: run the detector on every file, dump the map list per file, and diff against a reference (WinOLS pack, A2L, or your own verified annotations). The result I need to see is the same kind of table as above: N files, N at the expected map list, and the differences explained one by one.
Invariants from the ECU, not from the corpus. Once you have seen twenty CP31 files you will know what is always there (how many rail pressure maps, how many boost limiters, whether the smoke limiter always comes with its thermal twin, what grid the driver wish always has). Write those into the expected report, that is what turns the completeness badge into something users can trust.
Zero false positives on the VAG bench, which you already have, plus zero on whatever foreign 2 MB files you can find (PSA, BMW EDC16), because your gate runs before the VAG logic.
Drop the EGR OFF solution from the PR. Keep it in your fork if you like, it is well written; no solutions for now, that is a decision on my side, not a judgement on the code.
Until then the family stays out of the released app. I would rather it ships in a version where I can put "EDC16CP31" in the notes and mean it. When it gets there, integration will be done on my side (master keeps one commit per release, so there is no direct merge button here), with your name in the release notes and the README, and I would ask you to stay the reference person for Mercedes reports, since I cannot test them.

Two small things while you are in there: the "PORTING SKELETON" comment in bosch/mod.rs is outdated, and the package-lock version bump should go away, the version lives in the release.

I would leave the PR open and mark it as a draft in the meantime, so it stays the place where this lands. And if you want to talk about all this directly, the corpus, the invariants, how I run the benches, write to me on Instagram or wherever suits you (links on linktr.ee/zedperf), it is easier than a comment thread.

Thanks again, really. This is the best contribution the project has received, and I want it in. Just not at 70 %. Whatever happens next, you officially stay the first contributor on GitHub :)