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

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.

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 <module>
    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.