fix(project): add transactional plugin deletion lifecycle hook

[muzamilkm]

Summary

DELETE /projects/:projectName deletes core project state directly, but plugins had no deletion lifecycle extension point. A plugin that persists state tied to a DevLake project therefore had no way to validate or clean up that state when deletion went through the core API.

This PR:

• adds an optional plugin.ProjectDeleteHook alongside the existing project-related plugin contracts
• invokes implementing plugins through plugin.TraversalPlugin before core project deletion
• runs plugin cleanup, blueprint cleanup and core project cleanup inside the same database transaction
• adds BlueprintManager.DeleteBlueprintInTransaction so blueprint cleanup can participate in the caller's transaction while preserving the existing DeleteBlueprint(id) entry point
• safely handles projects without an associated blueprint during the unfinished-pipeline check
• adds regression coverage for optional hook dispatch, hook vetoes, rollback and successful single-transaction deletion

Existing plugins do not need to implement ProjectDeleteHook unless they persist state whose lifecycle is tied to a DevLake project.

Does this close any open issues?

Closes #9081

Screenshots

N/A

Other Information

Backwards compatibility

ProjectService remains unchanged and still only requires RenameProject(...).

ProjectDeleteHook is a separate optional plugin interface, so existing plugins and existing ProjectService implementations remain source-compatible.

The existing BlueprintManager.DeleteBlueprint(id) entry point is preserved. DeleteBlueprintInTransaction only provides a transaction-aware path for callers that already own a transaction.

There are no schema, migration, HTTP API, Config UI or Grafana changes in this PR.

Validation

From backend/:

go test ./core/plugin/... -count=1
go test ./helpers/pluginhelper/services/... -count=1
go test ./server/services/... -count=1

go vet ./core/plugin/... ./helpers/pluginhelper/services/... ./server/services/...

gofmt -w core/plugin/plugin_blueprint.go \
  helpers/pluginhelper/services/blueprint_helper.go \
  helpers/pluginhelper/services/blueprint_helper_test.go \
  server/services/project.go \
  server/services/project_test.go

git diff --check devlakeupstream/main...HEAD

All of the above pass locally.

The new hook contract is documented in core/plugin. No user-facing documentation changes are required.

[klesh]

Thanks for putting this up.
The overall design LGTM.
But I didn't see any actual implementation on the plugin side, what is the plan for that part?

[muzamilkm]

@klesh The intention was to keep this opt-in on the plugin side so existing plugins wouldn’t be forced to implement the new interface just because the framework supports it.

The idea was that plugins which actually have buffered/stateful resources that need flushing can implement it as needed, while the rest remain unchanged.

That said, if you’d prefer this PR to include concrete implementations for the existing plugins where it makes sense, I can go through them and add those as part of this PR.

[klesh]

@klesh The intention was to keep this opt-in on the plugin side so existing plugins wouldn’t be forced to implement the new interface just because the framework supports it.

The idea was that plugins which actually have buffered/stateful resources that need flushing can implement it as needed, while the rest remain unchanged.

That said, if you’d prefer this PR to include concrete implementations for the existing plugins where it makes sense, I can go through them and add those as part of this PR.

Makes sense. Please resolve the conflict and I will merge this PR first.

[muzamilkm]

Thanks @klesh I've resolved the conflicts and pushed.