Normalize timestamp format across data stores (epoch millis vs ISO-8601)

## Context

Raised by @jeromevdl in https://github.com/aws-samples/sample-collaborative-ai-dlc/pull/255 (see [review comment](https://github.com/aws-samples/sample-collaborative-ai-dlc/pull/255)):

> answeredAt is `Date.now()` here (current time in ms) and `new Date().toISOString()` (string) in the other lambda (question). Isn't there a problem? We should probably keep the same format everywhere [...] For the date, just wanted to be sure we don't try to compare things that are not comparable... and I fear we try at some point.

## Current state

Each store is internally consistent, but they differ from each other (pre-dates PR #255):

- **DynamoDB (agent-questions table):** epoch millis everywhere — `createdAt`/`answeredAt` written via `Date.now()` in the submit-question and answer-question lambdas; typed as `number` in `frontend/src/services/agents.ts`.
- **Neptune graph:** ISO-8601 strings throughout (rendered in the Q&A history).

A code comment documenting why the two writes differ was added in PR #255 (commit dd13383), but the underlying inconsistency remains.

## Risk

As long as the formats stay separated per store nothing breaks, but any future code path that compares or merges timestamps across the two stores would silently compare a `number` against a `string`.

## Proposed fix

Repo-wide normalization to ISO-8601:

- Switch DynamoDB timestamp writes to `new Date().toISOString()`.
- Make all readers (lambdas + frontend) tolerant of both formats during the transition, since existing rows contain epoch millis (mixing `number` and `string` values in the same attribute across old/new rows).
- Update frontend types in `frontend/src/services/agents.ts` accordingly.
- Optionally: a one-off migration for existing DynamoDB items so readers can eventually drop the dual-format handling.

Start with the submit-question and answer-question lambdas, then inspect frontend/src/services/agents.ts and the DynamoDB and Neptune timestamp handling. Trace all timestamp readers and writes, decide how the transition handles existing epoch-millisecond rows, and verify that new writes and frontend types consistently support ISO-8601 values.

Written by the indexing model from the issue text.