Add random auto-continue delay support

[DXinLei]

Summary

This PR adds support for configurable random auto-continue delay.

Supported delay formats:

• 5: fixed 5 seconds
• 5.5: fixed 5.5 seconds
• 5,9 / 5，9: random delay between 5 and 9 seconds

The delay input keeps the configured value, while the waiting status shows the actual randomized delay used for the current auto-send.

Behavior

Example configuration:

44,55

Example waiting status:

已生成续发内容，50.567 秒后发送，已用时 00:16

The elapsed timer updates by whole seconds to reduce UI rendering pressure, but auto-send still uses the actual randomized millisecond delay.

Notes

• Keeps backward compatibility with existing numeric delay values.
• Invalid ranges such as 9,5 or 5,5 are ignored and the previous valid value is kept.
• Storage continues to use the existing auto-continue delay key.
• The delay input only displays the configured value; the randomized value is shown in the waiting status.

[510myRday]

Thanks for the PR. The feature direction makes sense, and configurable random auto-continue delay is useful.

I reviewed the implementation and I don’t think this is ready to merge yet.

Current blockers:

1. npm run typecheck fails on the PR branch.
   The error is in src/content/runtime/contentRuntimeState.ts around parsed.error.

2. Existing runtime-state tests fail.
   The PR changes existing delay semantics:

   • negative values used to clamp to 0, now they fall back to the previous/default value
   • decimal values used to be floored, now they are preserved

   If this behavior change is intentional, the tests and expected behavior should be updated explicitly. Otherwise it should keep backward compatibility.

3. The random delay implementation is too fragile.
   It stores the delay as an object with valueOf() and decides whether to generate a random value by inspecting the call stack. This can break easily if function names change, code is refactored, or another Number(...) conversion happens somewhere else.

4. The floating widget UI also needs to be redesigned for this feature.
   The current UI is built around a simple numeric delay input. Random delay is a different interaction model, so it should be supported directly in the widget instead of patching the existing input with MutationObserver and setInterval.

   Suggested UI direction:

   • Add a clear mode switch: Fixed / Random
   • Fixed mode: one input, e.g. 5 seconds
   • Random mode: two inputs, e.g. 5 - 9 seconds
   • Keep the configured value visible in the widget
   • Show the actual resolved randomized delay only in the waiting status
   • Validate invalid ranges such as 9 - 5 or equal min/max directly in the widget

Suggested implementation direction:

• Represent the delay config explicitly, for example fixed vs range config.
• Resolve the random delay once at the auto-continue send point.
• Avoid using valueOf() and call stack inspection.
• Integrate the UI changes into the floating widget render/update logic directly.
• Keep storage backward-compatible with existing numeric delay values.
• Add tests for fixed delay, random range, invalid range, negative values, decimal values, and persisted config text.

I’m happy to review another iteration after these issues are addressed.