feat: Add ML pipeline STRIDE coverage

[purvanshbhatt]

Resolves the coverage gap for ML pipelines documented in the README.md where the tool previously returned 'Total findings: 0'.

This PR introduces intelligent STRIDE mapping for machine learning footprints (TAMPERING and ELEVATION_OF_PRIVILEGE). Because functions like torch.load and insecure deserialization in ML frameworks can lead to model poisoning and arbitrary code execution, mapping these to Tampering and EoP provides a vastly superior security audit than standard HTTP spoofing logic.

cc @mikedanese

[Marc-cn]

Thanks for the PR, Lint is failing, ruff errors in ml_test.py. Tests are failing too, please make sure the suite passes locally. Will review once CI is green.

[Marc-cn]

Thanks @purvanshbhatt, a few fixes needed:

1. The loader check matches any .load() call (json.load, yaml.load, etc.), not just ML ones, so it flags normal code as ML threats. Please only flag a load when an ML library is actually imported in that file
2. A plain import torch shouldn't create findings on its own, only real load calls should.
3. Please remove test_ml.py (repo root) and packages/darnit-hello/ml_test.py, they're scratch files. Put the real test in tests/darnit_baseline/threat_model/.
4. Revert the uv.lock change,this PR doesn't add dependencies.
   Happy to re-review when you push.

[Marc-cn]

Hi @purvanshbhatt, checking in on this one. It's been a few months since the review above and the branch has since picked up a conflict in tests/darnit_baseline/test_handler_dispatch_integration.py.

Still happy to take it if you want to pick it back up. The outstanding items are the same four:

1. Gate the loader check on an ML library actually being imported in the file, so json.load / yaml.load don't get flagged.
2. import torch alone shouldn't produce a finding.
3. Drop test_ml.py and packages/darnit-hello/ml_test.py; the real test belongs in tests/darnit_baseline/threat_model/.
4. Revert the uv.lock change.

Plus a rebase on main now.

If you'd rather not continue, no problem at all - just let me know and I'll close it so it's not sitting in the queue. The ML-pipeline coverage gap is still worth filling either way, so if you do want to come back to it later the issue stays open.