chore(workflow-engine): Modify cache utils to fix failing tests

[leeandher]

The cascade deletions cause issues with these caching functions. The test failures can be seen in the migration PR. I'm not too familiar with these utilities but from my understanding:

• It's causing failures because the cascade deletion order has changed
• with the NOT NULL key to Project: the Detector was always deleted before the Project, meaning Detector's post_delete fires, and that Project is still in the DB, so detector.project.organization (on the in-memory Detector) still works.
• with the nulllable FK to Project: Django does not ensure that Detector's post_delete happens before the Project row is removed. When the Project is removed first, the caching function hits the DoesNotExist error.

I consulted claude about this ordering change, who added:

the reason the ordering changes is specific to how Django's cascade collector works. It tracks dependencies between models to determine deletion order, but it only registers a dependency when the FK is NOT NULL (line 136 of django/db/models/deletion.py: if source is not None and not nullable). And the CASCADE handler passes nullable=field.null (line 27). So making the FK nullable literally removes the ordering constraint that kept Detector-before-Project, and the deletion order becomes arbitrary.

Previous PR: #120744
Next PR: #120687

[linear-code]

ISWF-3123

[sentry]

Sentry Snapshot Testing

Name	Added	Removed	Changed	Renamed	Unchanged	Skipped	Status
sentry-frontend sentry-frontend	0	0	0	0	451	0	✅ Unchanged

⚙️ sentry-frontend Snapshot Settings

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 081ffb5. Configure here.}

[saponifi3d]

rather than this returning none, can we raise an exception? My thought here is, I would expect every detector to belong to an org, and if it isn't then it should be treated as an error.

That would also mean that the function_cache wouldn't need to change 🎉 we'd just call into here, raise an unhandled exception, and catch that with sentry.