Segment summary regeneration runs eagerly and stale saves can close the active editor

## Description

Editing a knowledge-base segment that already has a generated summary currently causes three related problems:

1. Every content save regenerates the summary synchronously, even when the user is making several edits in quick succession. This consumes model quota for intermediate content and keeps the update request open during LLM/vector I/O.
2. If the user starts editing another segment before the previous save resolves, the earlier request's success callback closes the currently active segment drawer. The new in-progress edit can appear to disappear.
3. The document-level "Generating summary" badge is hidden until the document row is hovered, so background summary work is easy to miss.

## Reproduction

Tested on self-hosted Dify 1.16.1 with a high-quality knowledge base and summary indexing enabled.

1. Generate summaries for a document.
2. Edit the content of a summarized segment and save it.
3. Immediately edit the same segment again, or open another segment while the first request is completing.
4. Return to the document list without hovering the row.

## Actual behavior

- Each save immediately invokes summary generation.
- A stale save completion can close a newer segment drawer.
- The summary-generation badge is only visible on row hover.

## Expected behavior

- Automatic summary regeneration should be debounced until the user has stopped editing. A 10-minute window avoids spending model quota on intermediate revisions.
- Only the latest edit should be eligible to publish a regenerated summary.
- A manual summary update should cancel pending automatic regeneration.
- A save completion should only close the drawer for the segment that initiated it.
- The generating badge should remain visible while summary work is pending or running.

## Root cause

- `SegmentService.update_segment` calls `SummaryIndexService.generate_and_vectorize_summary` directly when segment content changes.
- The frontend close callback has no segment identity, so an older mutation can close whichever segment is currently selected.
- The summary status wrapper uses `hidden group-hover:flex`.

## Related work checked

- #39776 hardens summary-index consistency and concurrency, but still regenerates edited segment summaries synchronously and does not address the two UI behaviors.
- #36035 fixes missing document-level summary regeneration after Service API updates; it does not cover manual segment editing.

## Proposed fix

- Schedule segment summary regeneration on the existing `dataset_summary` queue with a 10-minute countdown.
- Use a per-segment Redis generation token and content hash check so superseded tasks cannot publish stale output.
- Mark the summary pending immediately, cancel pending work on manual summary edits, and retain error state if scheduling or execution fails.
- Pass the initiating segment ID through the frontend close callback.
- Keep the generating badge visible without hover.

From Codex

Start by tracing SegmentService.update_segment and SummaryIndexService.generate_and_vectorize_summary, then inspect the existing dataset_summary queue and Redis-related summary state. Review the frontend close callback and the hidden group-hover:flex wrapper. Done means debounced, cancellable per-segment regeneration prevents stale publication, drawer closure is scoped to its initiating segment, and the generating badge stays visible.

Written by the indexing model from the issue text.