[Feature]: Typed registry over entry points (backends / transports / schedulers)

## User Story

As a VO developer,
I want to register my own backend, transport or scheduler by shipping a package with an entry
point,
So that I extend interCEde without forking it — unlike DIRAC's `ObjectLoader` string-to-module
loading.

## Feature Description

IC-ADR-001 §5:

- Three entry-point groups: `intercede.backends`, `intercede.transports`, `intercede.schedulers`;
built-ins registered the same way (interCEde's own `pyproject.toml`).
- **Lazy, typed lookup**: import only the requested target; `isinstance` gate against the relevant
`@runtime_checkable` protocol at the boundary, failing fast with a clear error.
- **Data-driven resolution**: `registry.backend({"type": "arc", ...})` for monolithic;
`registry.backend({"transport": "ssh", "scheduler": "slurm", ...})` composes `BatchBackend` —
combinations never need their own registered class (N+M, not N×M).
- **Enumeration** for tooling ("what backends does this environment offer?") and a documented
name-collision/override precedence rule (site shadows a built-in without patching).
- Registry returns backends inside the managed-lifetime surface decided in #
(async context manager).

## Definition of Done

- [ ] Registry API implemented; entry-point groups documented
- [ ] Misregistered class fails at resolution with a clear error, not at first call
- [ ] Test with a dummy third-party plugin package (tmp venv/`pip install` fixture) proving
discovery + override precedence
- [ ] `FakeBackend` registered and resolvable — the conformance suite runs via
the registry path

## Alternatives Considered

- `ObjectLoader`/naming-convention loading (DIRAC) — untyped, undiscoverable, unversioned; rejected
by the ADR.
- Eager import of all entry points — slow startup, import errors in unrelated backends break
everything; lazy is required.

## Related Issues