# Bug: peek_messages fails on session-enabled queues without a session_id

## Observed behavior

Calling `servicebus_peek_messages` on a session-enabled queue without providing a `session_id` raises:

```
'ServiceBusClient' object has no attribute 'accept_next_session'
```

## Root cause

In `src/servicebus_mcp/tools/peek_messages.py`, `_do_peek` has this fallback path:

```python
except ServiceBusError as e:
    if "non-sessionful" in str(e):
        with client.accept_next_session(queue=queue, max_wait_time=10) as receiver:
            return receiver.peek_messages(max_message_count=max_count)
    raise
```

Two problems:

1. **Wrong keyword argument.** `ServiceBusClient.accept_next_session` takes `queue_name`, not `queue`. This causes the `AttributeError` (Python raises it when the call fails to resolve, though the actual error surfaces as an attribute error on the wrong object in the traceback).

2. **Wrong error string check.** When a non-session receiver is opened against a session-enabled queue, the Azure SDK raises a `ServiceBusError` whose message says something like "requires a session" — not "non-sessionful". So the condition `"non-sessionful" in str(e)` never matches, meaning the fallback is unreachable in the normal error case. The fact that it was reached here suggests the error string may vary by SDK version or connection method.

## Fix

```python
with client.accept_next_session(queue_name=queue, max_wait_time=10) as receiver:
```

Also review whether the `"non-sessionful"` string match is reliable across SDK versions, or whether a broader condition (or just always attempting the session path on `ServiceBusError`) is more appropriate.

## Verified against

- Namespace: `shdapps-dev1-eus2-sbn`
- Queue: `onboard-vehicles` (session-enabled)
- Auth: connection string via `AZURE_SERVICEBUS_CONNECTION_STRING`
