`serve()` fails on Python 3.14: `asyncio.get_event_loop()` raises instead of creating a loop

### What happened?

`crossplane.function.runtime.serve()` calls `asyncio.get_event_loop()` from a
synchronous context:

https://github.com/crossplane/function-sdk-python/blob/main/crossplane/function/runtime.py#L98

On Python 3.14 that raises instead of creating a loop, so any function built on
the SDK dies at startup:

```
Traceback (most recent call last):
File "/app/.venv/bin/my-function", line 10, in
sys.exit(main())
File "/app/function/main.py", line 42, in main
runtime.serve(
...
File "/app/.venv/lib/python3.14/site-packages/crossplane/function/runtime.py", line 98, in serve
loop = asyncio.get_event_loop()
File "/usr/local/lib/python3.14/asyncio/events.py", line 718, in get_event_loop
raise RuntimeError('There is no current event loop in thread %r.'
% threading.current_thread().name)
RuntimeError: There is no current event loop in thread 'MainThread'.
```

`get_event_loop()` creating a loop when none is running was deprecated in 3.12
and removed in 3.14; the call now only succeeds from inside a running loop.

### How can we reproduce it?

Scaffold from `function-template-python`, set the base image to
`python:3.14-slim`, build, and run the entrypoint — the process exits
immediately with the traceback above. Nothing else is needed; it fails before
any request is served.

### What is the SDK version?

`crossplane-function-sdk-python` 0.14.0 (current release), and `main` at the
time of writing still has the same call.

### Why this may have gone unnoticed

`pyproject.toml` declares `requires-python = ">=3.11"`, but CI pins a single
version — `PYTHON_VERSION: '3.11'` in `.github/workflows/ci.yml` — so nothing
exercises the upper end of that range. 3.13 still accepts the call (deprecated
only), which is why this surfaces first on 3.14.

### Additional context

Found while testing a Python 3.12 → 3.14 bump on a function of ours. Worth
flagging how quiet the failure is: on 3.14 the image builds, every dependency
imports, and the full unit suite passes. Only starting the entrypoint fails, so
the bump looks green everywhere except in a cluster, where it crash-loops.

Happy to test a patch against a real function if that helps — not opening a PR
myself, since `serve()` also installs signal handlers and calls
`run_until_complete` on that loop, and how you want it restructured (own loop
via `new_event_loop`, or moving to `asyncio.run`) is a design call for you.

Start in crossplane/function/runtime.py around line 98 and trace serve() through its signal-handler setup and run_until_complete call. Compare the declared Python range in pyproject.toml with the single-version coverage in .github/workflows/ci.yml, then reproduce the failure using function-template-python with python:3.14-slim. Done means the entrypoint starts and serves requests on Python 3.14 without breaking the existing suite.

Written by the indexing model from the issue text.