feat(admin,divide): draining admission lets instances stop receiving new work without deregistering (#8042) - #8101

First delivery slice of #8042: the draining admission boundary — a registered business instance can declare that it is alive but must stop receiving new work, and gateways stop selecting it while it keeps serving the work already admitted.

Problem

Today the only way to take a registered instance out of rotation is the offline path, which removes it from the configuration outright: in-flight work loses its target, and a restarting process must fully re-register. There is no intermediate state between "enabled" and "gone", and instance health (instance_state) is display-only — it never influences upstream selection.

Change

• A client declares draining through the existing URI registry with a new EventType.DRAINING (HTTP SDK: ShenyuClientRegisterRepository.draining, reusing the URI registration endpoint — no new admin endpoint).
• Admin merges a draining marker into the discovery upstream's free-form props (markDrainingBySelectorIdAndUrl, idempotent, preserving existing keys such as warmup/gray/labels) and publishes the normal DISCOVER_UPSTREAM update, so every gateway replica converges through the existing sync channel.
• The marker deliberately does not use the enabled/status column: heartbeats and health probes flip that column back and forth. Because the heartbeat path only updates the status column, a draining instance that keeps beating is never re-admitted — the "heartbeats must not cancel a drain" requirement is structural, and locked by a test.
• Gateways parse draining from props (UpstreamProps), carry it on the loadbalancer Upstream (outside its identity), and UpstreamCacheManager routes draining instances out of both the healthy and unhealthy pools: no new selection returns them, no probe can restore them, and a later sync without the marker re-admits them through the regular paths.
• A fresh registration releases the drain — the registration path explicitly clears the marker, so a restarting replacement process claims its identity back, while heartbeats alone can never do so. The generation-scoped stale-drain handshake from the issue is left to a later phase together with ready/not-ready states and propagation deadlines.

Tests

• Exclusion: Two upstreams with one draining → the candidate set contains only the sibling; the draining instance sits in neither health pool; a marker-free sync re-admits it. All-draining → no selectable upstream (the divide empty-pool 503 path already covers it).
• Red/green: Removing the cache-manager routing makes exactly the two new exclusion tests fail; restoring it turns 19/19.
• Heartbeat lock: The heartbeat path asserts updateStatusByUrl only — never a props write.
• Admin: Props merge preserves existing keys and is idempotent; unknown handler/url are ignored; the subscriber dispatches DRAINING grouped by namespace.

Verification

UpstreamCacheManagerTest: 19
UpstreamPropsTest: 11
DivideUpstreamDataHandlerTest: 23
divide module: 125
shenyu-admin: 2427

All green; checkstyle clean on all eight touched modules.

Out of scope (later phases per the issue)

ready/not-ready state model, generation-scoped drain handshake, propagation deadlines/disconnect behavior, gRPC entity mapping, admin UI.