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

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