server/services: add optional DeleteProject hook for plugin-owned project state

[bujjibabukatta]

Summary

Fixes #9081. The generic DELETE /projects/:projectName flow
(services.DeleteProject) has no lifecycle hook for plugins/features
with project-scoped state, unlike PatchProject's rename flow, which
already calls projectService.RenameProject(...). Feature-owned
records can be left stale or orphaned when a project is deleted
directly through this endpoint.

Root Cause

ProjectService only defines RenameProject. DeleteProject deletes
core records (project, mappings, metric settings, blueprint) with no
equivalent extension point, so any plugin/feature relying on its own
project-deletion flow to clean up state never gets invoked when
deletion happens through the core API.

Fix

• Added ProjectDeleteHook, a separate optional interface (not a new
  required method on ProjectService), so existing downstream
  implementations that only support renaming aren't broken.
• DeleteProject now checks via type assertion whether the injected
  projectService also implements ProjectDeleteHook, and if so
  invokes it inside the same deletion transaction, before core rows
  are deleted — a hook error rolls back the whole deletion, and any
  cleanup it performs commits atomically with core deletion.

Known limitation: deleteProjectBlueprint(name) runs before the
transaction/hook, so a hook veto can't stop the blueprint from already
being deleted. Not addressed in this PR — flagging for a possible
follow-up.

[klesh]

This doesn't make sense. You want plugins to depend on the backend/server package? Do you even understand the code you submitted? Please don't pick an issue you don't understand and generate random code, especially since the author of #9081 stated they will submit a PR for this matter.