feat: Sequential numbering for forked session titles (Issue #10105)

[ariane-emory]

What does this PR do?

Instead of four sessions receiving generic session titles, such as New session - 2026-01-22T14:30:00.000Z, sequential numbering will be applied: #2 will be suffixed onto the title the first time it is forked, #3 the second time, and so on.

Before forking

After forking once

After forking twice

Resolves #10105.

How did you verify your code works?

Manual testing: the feature works, but unfortunately, as shown in the screenshots, GLM 4.6's sense of humour does not appear to have improved.

[github-actions]

The following comment was made by an LLM, it may be inaccurate:

No duplicate PRs found

[rcdailey]

Questions:

• What happens if you fork a fork (I've never seen if OC prevents this; I assume it does not)
• Do you have a screenshot of the session list? How do long session names get rendered in that session list when the terminal width isn't wide enough?

[ariane-emory]

@rcdailey Check out the screenshots: the number is incremented by 1.

This is a screenshot of my session_list right now, shown in a very narrow window for demonstration purposes:

As you can see, the display of excessively long session titles can be truncated when the window is too narrow, but the remaining text will become visible if the window is widened.

Personally, I'm not sure exactly what (if anything) can or should be done about that detail and, in any case, it seems to me like changing that behaviour (if change is desired) would be out of scope for this particular issue related to the naming of forked sessions.

I would personally prefer to keep this PR tightly scoped and laser-focussed on the single topic of forked session titles instead of trying to address multiple issues in one PR (which is rarely a good idea or likely to be merged). If you're unsatisfied with the way that long session names are displayed in the session list (personally I think that the current behaviour does make sense), I think that that topic would be best addressed in a separate issue.

[rcdailey]

I just really appreciate the engagement and answers to my question. I wouldn't ask for you to do additional work. Those were just thoughts. Thanks again for doing this!

[ariane-emory]

@rcdailey No problem at all, and don't hesitate to ask - I'm always happy to help when I'm able. :)