Play Framework

fix(controller): collapse Javaflow await path into unconditional inline-block

Step 1/4 toward eliminating Javaflow. The four await(...) overloads previously
branched on VirtualThreadConfig.isInvokerEnabled(): VT mode took the inline
Thread.sleep / future.get path, platform mode took the Javaflow Continuation /
Suspend path. The platform path captured the controller's stack via Javaflow
bytecode enhancement and resumed on a fresh Invocation, which caused
ThreadLocal-bound resources (JPA EntityManager + JDBC connection most
visibly) to be orphaned across the suspend.

Inline-block on both paths is the right answer:
- VT: the carrier yields automatically on Thread.sleep/future.get; the same VT
  resumes after wake with all ThreadLocal state intact.
- Platform thread: blocks the thread, same as any JDBC call. Non-scalable
  under contention, but correct; users who need scaling enable VT mode.

Removes from Controller:
- Imports: org.apache.commons.javaflow.Continuation,
  org.apache.commons.javaflow.bytecode.StackRecorder,
  play.classloading.enhancers.ContinuationEnhancer,
  play.classloading.enhancers.LocalvariablesNamesEnhancer (bare),
  play.exceptions.ContinuationsException, play.utils.VirtualThreadConfig
- Methods: storeOrRestoreDataStateForContinuations,
  verifyContinuationsEnhancement, shouldBeCheckedForEnhancement
- Conditional Javaflow branches in await(int), await(int,Action0),
  await(Future), await(Future,Action)

Removes the now-meaningless ControllerTest.shouldBeCheckedForEnhancement test.

ant unittest passes; the rest of the Javaflow scaffolding (ActionInvoker
plumbing, ContinuationEnhancer, commons-javaflow jar) goes in subsequent
commits.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>