Migrate KEDA HTTP scaling from HTTPScaledObject to ScaledObject with external trigger

## Problem

Currently, the KEDA deployer uses `HTTPScaledObject` for HTTP-based autoscaling. This creates an internal `ScaledObject` under the hood, which means we cannot create a second `ScaledObject` for the same Deployment (e.g. for Kafka consumer-lag scaling). KEDA's admission webhook rejects it:

```
admission webhook "vscaledobject.kb.io" denied the request: the workload 'my-func'
of type 'apps/v1.Deployment' is already managed by the ScaledObject 'my-func'
```

This makes it impossible to combine HTTP + Kafka triggers on the same function.

## Proposed solution

Replace `HTTPScaledObject` with a single `ScaledObject` that uses the KEDA HTTP add-on's external scaler as one of its triggers, alongside any other triggers (Kafka, cron, etc.).

The HTTP add-on exposes an external scaler gRPC endpoint that a regular `ScaledObject` can reference via an `external` trigger. The interceptor routing can be handled via `InterceptorRoute` (or the HTTP add-on's route CRD) instead of relying on `HTTPScaledObject` to set it up.

This would:
1. Allow combining HTTP + Kafka (or any other) triggers in a single `ScaledObject`
2. Give us direct control over all trigger configuration in one place
3. Remove the hidden internal `ScaledObject` that `HTTPScaledObject` creates

## Current workaround

Users must choose either HTTP-only or Kafka-only triggers — they cannot be combined.

## References
- KEDA HTTP add-on external scaler: the add-on runs a gRPC external scaler service
- KEDA limitation: one `ScaledObject` per workload

Start by locating the KEDA deployer code that creates HTTPScaledObject resources and reviewing how other triggers are assembled. Verify the KEDA HTTP add-on external scaler and InterceptorRoute or route CRD integration; done means one ScaledObject can combine HTTP and other triggers without the duplicate-workload admission error.

Written by the indexing model from the issue text.