Track follow-up hardening for Lark relay registration backfill UX and diagnostics

[eanzhao]

Background

PR #389 fixes the blocking cross-tenant safety issue for empty-scope Lark relay registration backfill. A few non-blocking follow-ups remain useful for operational clarity and historical fidelity.

Follow-ups

1. Expose clearer backfill outcome in rebuild responses

   • Today a projection rebuild still returns 202 accepted even when selected backfill is rejected, with the rejection only embedded in note.
   • Consider adding a structured field such as backfill_status: skipped|verified|rejected and/or warnings[], so CLI/UI callers do not misread a rebuild dispatch as a successful backfill.

2. Make empty ScopeId registration commands observable

   • ChannelBotRegistrationGAgent.HandleRegister currently logs and returns when ScopeId is empty.
   • This is fine as a defense-in-depth invariant guard, but add stronger operational visibility, e.g. diagnostic event/metric and possibly LogError, so an upstream contract break is visible.

3. Preserve original CreatedAt during scope repair

   • The current backfill path re-registers entries, so CreatedAt is refreshed.
   • Consider a dedicated scope-backfill command/event that repairs ScopeId while preserving original creation time, or otherwise records enough audit detail for historical debugging.

Acceptance ideas

• Rebuild/backfill API responses make skipped/rejected/verified backfill states machine-readable.
• Empty-scope register attempts are visible through diagnostics/metrics, not only a warning log.
• Backfill can repair ScopeId without losing the original registration creation timestamp, or the audit trail clearly captures that rewrite.