session/database: support gorm NamingStrategy for adk table names

### Is your feature request related to a specific problem?
Yes.

I am integrating `google.golang.org/adk/session/database` into an existing Go application that uses a shared Postgres database. I need the ADK session tables to be namespaced so they do not collide with existing or future application tables and so their ownership is obvious during operations/debugging.

The problem is that `session/database.NewSessionService(...)` already accepts `...gorm.Option`, so it is natural to expect standard GORM configuration to apply, including table naming configuration such as `gorm.Config{NamingStrategy: ...}`.

For example, I expected something like this to work:

```go
service, err := sessiondatabase.NewSessionService(
postgres.New(postgres.Config{Conn: sqlDB}),
&gorm.Config{
NamingStrategy: schema.NamingStrategy{
TablePrefix: "adk_",
},
},
)
```

However, the ADK session tables still use fixed names like:

- sessions
- events
- app_states
- user_states

From a caller perspective, this is surprising because the API already exposes GORM options.

### Proposed Solution

Please make the database-backed session store respect standard GORM table naming configuration for its internal tables.

In practice, this would allow configurations like:

```go
service, err := sessiondatabase.NewSessionService(
postgres.New(postgres.Config{Conn: sqlDB}),
&gorm.Config{
NamingStrategy: schema.NamingStrategy{
TablePrefix: "adk_",
},
},
)
```

to produce tables such as:

- adk_sessions
- adk_events
- adk_app_states
- adk_user_states

Default behavior should remain unchanged for users who do not provide custom GORM naming configuration.

If maintainers would rather not rely on GORM naming strategy for this, an explicit ADK option for table prefix or table name overrides would also solve the use case. But since the API already accepts ...gorm.Option, honoring standard GORM naming behavior seems like the most natural solution.

### Impact on your work

This affects our ability to adopt the ADK database session store cleanly in a production application that already has its own database conventions.

———

## 🟡 Recommended Information

### Alternatives Considered

Forking or vendoring the ADK session database implementation.

If this direction seems acceptable, I would be happy to help with a PR.