Add a client-activity workflow event provider - #53082

Part of #51595.

Workflows can already react to a client authenticating, but that event is EventType.CLIENT_LOGIN, which only the client_credentials grant emits. A public authorization-code client — what dynamic client registration produces — never raises it. So a CLIENTS workflow meaning "disable this client if it has been idle for N days" silently degrades to "N days after it was created" for exactly the population most likely to accumulate.

This adds client-activity over LOGIN, CODE_TO_TOKEN and REFRESH_TOKEN, so any use of the client resets the timer.

The *_ERROR variants are deliberately excluded. They carry the client id too, so counting them would let failed authentication against a dormant client keep it alive indefinitely — a property worth stating explicitly, since it is the kind of thing that looks like an oversight later.

The first commit is a separate defect

JpaWorkflowStateProvider schedules steps with Instant.now() while the due-check queries against Time.currentTimeMillis():

entity.setScheduledStepTimestamp(Instant.now().plus(duration).toEpochMilli());   // real clock
...
cb.lessThan(stateRoot.get("scheduledStepTimestamp"), Time.currentTimeMillis());  // offsettable clock

Under any time offset the due-check moves and the schedule does not, so steps fire at the wrong time. This is independent of the event provider and affects existing workflows; it is first here because the activity test cannot express "the timer resets on use" without both sides agreeing on a clock. Happy to split it into its own PR if you would rather review it separately.

It also changes BrokeredUserLifecycleWorkflowTest's offsets from 5/10/10 to 5/15/25. That test was passing for the wrong reason: with scheduling on the real clock the offsets were not actually cumulative. They are now, and the comment there says so.

Testing

New integration test covering activation on use and the reset behaviour, plus a case pinning that failed logins do not activate.

Verified locally: model/jpa compiles, tests/base test-compiles, and mvn spotless:check -pl model/jpa is clean. I have not run the integration test against a server locally — it is written to the same shape as the sibling activation tests.

Context: this was originally part of #51629, which I have closed since the client-attribute condition it also carried is superseded by #52189. #52189 does not include an activity event, so this half is still open and is here on its own.