fix(security): the RASP opt-in guide promises a freerasp upgrade that adds a detection fails the build, but the unpinned recipe and a new non-Threat ThreatCallback slip through silently #994

Found in the security review of #927 (PR #993, main 2fc1eec).

Summary

docs/guides/security/implementation.md:701 (the paragraph under "What the adapter forwards") tells an adopter that "a freerasp upgrade that adds a detection therefore fails flutter test until someone maps it, and the exhaustive switch in FreeRaspServiceImpl.securityThreatFor stops compiling first". Line 671 says the adapter forwards every detection "the pinned freerasp (8.2.4)" reports.

Since #993, neither statement fully holds:

1. Nothing pins freerasp any more. The opt-in recipe (implementation.md:615) runs flutter pub add freerasp:^8.2.4, which resolves the newest 8.x on the day the adopter enables RASP. That adopter has never run the adapter against 8.2.4, and no lock bump in this repository reviews the jump.
2. The guard only covers Threat enum values. The exhaustive switch and the test template's Threat.values loops (test/core/security/infrastructure/freerasp_service_impl_test.dart.template:143-199) catch a new Threat. They do not catch a new detection that freeRASP delivers on its own ThreatCallback parameter outside the Threat stream. freerasp 8.2.4 already does this for malware: onMalware uses its own pigeon channel. ThreatCallback's parameters are all nullable named parameters (freerasp/lib/src/callbacks/threat_callback.dart:23), so a new one compiles with the adapter leaving it null. freeRASP then drops that detection without logging it, which is exactly the failure fix(security): FreeRaspServiceImpl silently drops 13 of freeRASP's 23 threat callbacks (malware, bootloader, automation, ...) #390 fixed. The adapter's comment "One argument per ThreatCallback parameter" (lib/core/security/infrastructure/freerasp_service_impl.dart.template, above ThreatCallback() is not enforced by anything.

Exposure path: freerasp 8.x+1 adds a detection as a new ThreatCallback parameter, delivered like malware. The adopter follows the recipe and gets that version. The switch compiles and the renamed tests pass. The adopter believes the guide's promise that an unmapped detection fails the build, and ships with that detection silently dropped. This is misleading security documentation plus a hardening gap in the opt-in path. It does not affect the default build, which runs NoOpRaspService. freerasp's latest is still 8.2.4 today (pub.dev API, 2026-10-31), so nobody is exposed yet.

Acceptance criteria

1. Either the recipe pins the exact version the template was written for (flutter pub add freerasp:8.2.4), and the guide says that moving off it means re-checking ThreatCallback, or the guide drops the word "pinned" and states which freerasp range the adapter was checked against.
2. Either the test template fails when ThreatCallback has a parameter the adapter does not pass (for example a test that lists the constructor's named parameters from the resolved package source, through package_config, and compares them with the set the adapter passes), or implementation.md line ~701 is reworded to say the guard covers new Threat values only, and that a new non-Threat callback must be checked by hand on every upgrade.
3. flutter test test/tooling/rasp_is_opt_in_test.dart still passes, and Docs check is green.
4. Running the renamed tests against a real freerasp is outside the default suite, because the dependency is opt-in. The evidence must show how criterion 2 was exercised: either the renamed template run once in a scratch checkout with freerasp added, with its log committed, or a statement that the docs-only route was chosen.