Follow the applied assignment type for schema sources

[define-null]

Why

After the engine bump in #76, the CDN's old schema layout fails to parse, while the scheduler's bundle already uses the new layout. Workers continued polling the CDN even after applying a split assignment whose chunks resolve schemas by ID.

The bundle loader also rejected any existing schema ID republished with different bytes. This made workers with cached schemas reject updates that fresh workers accepted.

What changes

The assignment applier owns a concurrent CDN refresh task:

• It starts initially so legacy schemas load in parallel with assignment fetching.
• Successfully applying a split assignment cancels and awaits the task, interrupting in-flight HTTP requests and retry waits.
• Successfully applying a legacy assignment starts the task if absent, with an immediate refresh. Further legacy assignments reuse the running task.
• Refused or failed assignment updates leave the task unchanged. Previously loaded type schemas remain available after it stops.

CDN fetch or parse failures do not fail or block legacy assignment application. The task retains previously loaded schemas and retries with exponential backoff. Before the first successful load, dynamic queries requiring type schemas return server_error. Split assignments still require their separate schema bundle to download, validate, and install successfully.

The watch channel and separate CDN subsystem are removed. The applier observes refresh-task failures, and dropping it aborts any remaining refresh task. The end-to-end harness uses the same ownership model.

A bundle that republishes an existing schema ID with different contents replaces its stored file and loaded schema. Identical files remain untouched, and IDs absent from the new bundle remain in the accumulated store.

Validation

• All 115 tests passed with cargo test --locked --offline --all-targets.
• The strengthened assignment-transition test also passed separately, checking that failed split installs leave the existing CDN task running.
• Coverage includes immediate startup/restart, repeated starts without duplicate tasks, refused and failed assignment transitions, cancellation during manifest and schema HTTP requests, retry cancellation, retention of loaded schemas, and propagation of refresh-task panics.
• Bundle replacement is tested with both bundle-installed and startup-adopted schemas.
• cargo fmt --check and git diff --check passed. Clippy reports only the existing warning in polars_target.rs.

README and the relevant schema-source specifications are updated.

Remaining behavior

• Legacy workers still need the CDN YAMLs republished in the new layout to serve affected dynamic queries. This change does not repair those documents.
• The initial CDN task may log a warning before the first split assignment applies.
• Type schemas are not persisted. Retained chunks outside the current split assignment can lack a type schema if no CDN load succeeded before the task stopped.
• Bundle installation still uses individual file renames; this change does not make multi-file replacement transactional.