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

[JWThewes]

Context

Raised by @jeromevdl in #255 (see review comment):

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.