[Task] Fence stale business-instance heartbeat and offline requests with boot-session identity #8040

Goal

Prevent delayed requests from an earlier business-service process from renewing or removing a replacement instance using the same logical address/identity.

Scope

• Distinguish stable namespace/service/instance identity from an Admin-validated registration session or generation for each startup.
• Specify creation/retry semantics, concurrent registration ownership and generation handling across multiple Admin nodes.
• Require generation checks for negotiated heartbeat, offline and relevant instance updates. Specify observable stale-generation responses and client recovery.
• Ensure idempotent registration retries do not continuously replace the active generation; define how a genuinely new startup acquires ownership.
• Treat generation as fencing, not authentication: retain credential and namespace/service authorization checks and avoid exposing reusable secrets in logs.
• Document behavior for legacy v1 clients without session identifiers and mixed-version rollouts; do not silently reject old clients.

Acceptance criteria

Start process A, replace it with B under the same logical identity, then deliver A's delayed heartbeat/offline/update. B remains unaffected. Cover concurrent Admin writers, retry races, address reuse, Admin restart and provider-managed registrations using a documented policy.

Scope is application upstream registration, not MQTT session takeover or gateway-management command fencing. Related: registration lease task, #7602 and heterogeneous registration OpenAPI parent #8038.