Event Processor Lambda always sets change_type to "unknown" for EventBridge S3 notifications

## Summary

`src/event_processor_lambda.py` derives the S3 event type from `detail.name`, but EventBridge does not populate `detail.name` for S3 notifications. As a result, every S3 event delivered via EventBridge ends up with `change_type = 'unknown'`, and the downstream change tracking / SQS notification path cannot distinguish create vs. delete.

## Affected file

- `src/event_processor_lambda.py`

## Environment

- Default deployment from this repository's `main` (no modifications to the event-source wiring).
- S3 → EventBridge → Event Processor Lambda (the documented data flow).

## Steps to reproduce

1. Deploy the stack with the default configuration.
2. Upload an object under the watched prefix, e.g.
`aws s3 cp sample.pdf s3:////`
3. Inspect the Event Processor Lambda CloudWatch Logs and the tracking DynamoDB table.

Expected: a change record with `change_type = "create"` is produced, and the SQS message carries the same value.

Actual: `event_name` resolves to `""` and `get_change_type("")` returns `"unknown"`. The downstream SQS message / tracking record carries `change_type = "unknown"`.

## Root cause

EventBridge wraps S3 notifications with top-level `detail-type` values such as:

- `Object Created`
- `Object Deleted`
- `Object Restore Completed`

and does **not** set `detail.name`. The current code at `src/event_processor_lambda.py` reads:

```python
event_name = detail.get('name', '')
```

so `event_name` is always `""` for EventBridge-sourced events, and `get_change_type("")` falls through to `return 'unknown'`.

Reference for the EventBridge S3 event shape:

## Proposed fix

1. For EventBridge events, read the event type from the top-level `detail-type` field instead of `detail.name`.
2. Extend `get_change_type` to map EventBridge values (`Object Created`, `Object Deleted`, `Object Restore Completed`) in addition to the existing S3 direct notification values (`ObjectCreated:*`, `ObjectRemoved:*`, `ObjectRestore:Completed`) so both delivery modes remain supported.

A reference implementation in my fork: revsystem/sample-automatic-sync-for-bedrock-knowledge-bases@f329f89

If this matches your understanding, I'd be glad to send a PR per CONTRIBUTING.md. Happy to adjust the approach (e.g., dispatching on a different signal) if there is a preferred design.

Start in src/event_processor_lambda.py by tracing how the event payload is read and how get_change_type maps event names. Compare the existing direct S3 notification values with the EventBridge detail-type values described in the issue. Done means create, delete, and restore events produce the expected change_type for both delivery modes and that value reaches the tracking record and SQS message.

Written by the indexing model from the issue text.