docs(py): Explain why on_response() is safe without a lock

[jat255]

This fixes a docstring in the conversation history code. It said on_response() is safe because of a lock that py-shiny no longer takes.

Summary

The HistoryController.on_response() docstring said that on_response() is safe without a lock because "Shiny serializes reactive flushes behind a single process-wide reactive.lock()". posit-dev/py-shiny#2508 removes Shiny's use of that lock, and posit-dev/py-shiny#2520 deprecates it. The new docstring states the two guarantees that keep the method safe:

• Shiny does not start a new run of an effect while its previous run continues, so two calls from _save_on_response cannot overlap.
• Client inputs trigger the other effects that change self.record. Shiny holds input changes until all effects of the session are finished, so those effects cannot run while on_response() is paused at an await.

Review Notes

• Both guarantees are true in the current Shiny release and also with feat: Run reactive effects py-shiny#2508. You can merge this PR before or after that release.
• This PR changes only a docstring. There is no code change and no changelog entry.
• I checked the second guarantee against feat: Run reactive effects py-shiny#2508. When an effect of a session is invalidated, the busy count of the session increases, whatever the trigger was. Input updates wait until the busy count is zero.

Testing

ruff check passes. ruff format --check reports a difference on one line that this PR does not change. The same difference is on main.

Refs posit-dev/py-shiny#2508, posit-dev/py-shiny#2520