Legacy deploy.deployer-only functions lose deployer intent on `func delete` then `func deploy`

### Summary
A pre-#3953 `func.yaml` recorded the deployer only under `deploy.deployer` (the top-level `deployer` intent field didn't exist yet). For such a legacy function with a **non-knative** deployer (`raw`/`keda`), running `func delete` and then `func deploy` silently redeploys it as the default `knative` deployer.

### Cause
- `func delete` clears the observed `Deploy.Deployer` (`pkg/functions/client.go:1267-1268`).
- The intent field `f.Deployer` was never populated for these legacy files, so after delete **both** the intent and observed deployer are empty.
- The next `func deploy` then falls back to the default deployer (`knative`) via `config.Apply` (`pkg/config/config.go:136-141`).

Note: a plain `func deploy` (no delete in between) is **not** affected — `config.Apply` recovers the deployer from the observed `Deploy.Deployer`. Only the delete-then-redeploy path loses it.

### Scope
Pre-existing on `main`, independent of the KEDA scaling work. Narrow blast radius (legacy pre-#3953 file + non-knative deployer + delete-then-redeploy).

### Context
PR #4051 originally carried a fix for this inside the `0.38.0` scale migration (promoting the legacy `deploy.deployer` to `f.Deployer` intent), but it was removed there as unrelated scope. This ticket tracks doing it properly as its own change (e.g. a dedicated deployer-intent migration with tests).

Start in pkg/functions/client.go at the deployer clearing logic and pkg/config/config.go at config.Apply's deployer fallback. Trace how a legacy func.yaml is represented through delete followed by deploy, then add focused tests for preserving the non-knative deployer intent; done means the legacy raw or keda function redeploys with its original deployer.

Written by the indexing model from the issue text.