fix(my-account): raise rate limits on the logs view/export endpoints

Customers reported being locked out for many hours after a single log
debugging session. The /my-account/logs endpoints are read-only and are
the primary surface for monitoring the service, debugging delivery, and
configuring alias rules (especially during the first weeks of onboarding).
Each page load, each retry after a transient error, and each export
consumed one request against fairly low daily caps:

  * list logs       100 -> 1000 per day
  * download logs    10 ->  100 per day
  * retrieve a log  100 -> 1000 per day

Paginating through ~16 pages, hitting an occasional error, and exporting
are all legitimate usage, so the old caps produced false-positive lockouts
that made logs effectively unusable for active operators.

This only changes the numeric limits (and the formatting of the
/logs/download route to a multi-line call to match the surrounding style).
The limiter mechanism is unchanged: admins and accounts with the
is_rate_limit_whitelisted flag still bypass rate limiting entirely (see
config.rateLimit.id / userFields.isRateLimitWhitelisted), and the per-user
keying is unchanged.

Note: this does NOT address the separate "internal server error" some log
pages return, nor the truncated export row count — those are tracked
separately as a query/aggregation issue and are not part of this change.