Runtime panic(...) calls outside startup

[DagyOE]

Description

Several panic calls in runtime code (not config) represent invariant violations. They are caught by the request-level recovery, but it is cleaner to turn them into proper error returns:

[internal/cluster/jobmanager/server.go:287](internal/cluster/jobmanager/server.go)
[internal/grpc/server.go:179](internal/grpc/server.go), [:182](internal/grpc/server.go)
[internal/cluster/controller/controller.go:217](internal/cluster/controller/controller.go)
[internal/cluster/partition/partition_persistence.go:273](internal/cluster/partition/partition_persistence.go)
[internal/rest/server.go:1658](internal/rest/server.go), [:1675](internal/rest/server.go), [:1690](internal/rest/server.go)
[pkg/bpmn/engine.go:708](pkg/bpmn/engine.go), [pkg/bpmn/runtime/types.go:377](pkg/bpmn/runtime/types.go)

Acceptance Criteria

• Panics inside ZenBPM-owned goroutines/background workers are recovered and logged with stack trace.
• Goroutines that can report failure return or propagate an error; fire-and-forget goroutines at least log structured context.
• Existing intentional startup/config panics remain allowed.
• Runtime protocol/default-case panics are replaced with normal error handling where possible.
• Tests cover:
  • panic inside a spawned goroutine/background task
  • at least one runtime protocol/default branch returning an error instead of panicking