ACP session ID is reused after session/delete

## Summary

We observed Goose returning the same session ID for two different successful `session/new` calls on the same long-lived stdio ACP connection.

## Observed sequence

1. The client calls `session/new` and receives a session ID.
2. The invocation completes.
3. The client calls `session/close` and `session/delete`, based on the capabilities advertised by Goose.
4. The client calls `session/new` again.
5. Goose may return the same session ID for the new conversation.

Goose currently derives the ID from the current maximum daily suffix in its session storage. After the highest session row is deleted, that ID may become available again.

## Interoperability concern

The ACP specification says that `session/new` must return a unique session ID identifying the conversation, but it does not clearly define whether an ID may be reused after `session/delete`.

Different ACP agent-runtime may therefore implement different ID lifetimes. A generic ACP client may reasonably retain recently used IDs to protect notification routing and session state, causing valid-looking behavior from one agent to be treated as an error.

This creates an interoperability trap for ACP client developers.

## Suggestion

Would the Goose team consider generating session IDs that are not reused for different conversations, even after `session/delete`?

Possible directions include using an opaque unique identifier or a persistent monotonic allocation mechanism.

It may also be worth clarifying the expected lifetime of session ID uniqueness in the ACP specification.

Thank you for taking a look.