[BUG][KOTLIN][MULTIPLATFORM] Generated code requires @OptIn(kotlin.time.ExperimentalTime::class) after upgrading to kotlinx-datetime 0.7.1

Bug Report Checklist

Checklist
Provided minimal spec to reproduce the issue
Validated input with OpenAPI validator
Tested with latest master (7.14.0)
Searched for related issues/PRs

Description
When generating Kotlin multiplatform client code with dateLibrary=kotlinx-datetime, the generated classes produce errors if the project uses kotlinx-datetime:0.7.1.

The issue:
This declaration needs opt-in. Its usage must be marked with '@kotlin.time.ExperimentalTime' or '@OptIn(kotlin.time.ExperimentalTime::class)'

This happens because kotlinx-datetime introduced new APIs in 0.7.x that are annotated with @ExperimentalTime.

openapi-generator version
7.14.0

Generation Details
Gradle configuration:
openApiGenerate {
inputSpec.set("$rootDir/shared/openapi/api.yaml")
generatorName.set("kotlin")
library.set("multiplatform")
additionalProperties.set(
mapOf(
"dateLibrary" to "kotlinx-datetime"
)
)
}

Dependencies:
implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.7.1")

Steps to reproduce

1. Use the config above with OpenAPI Generator 7.14.0
2. Set dependency to kotlinx-datetime:0.7.1
3. Build the project → compilation fails with opt-in error messages

Actual Output

Generated models (e.g., LocalDateTime usage) require @OptIn(kotlin.time.ExperimentalTime::class) annotations.

Expected Output

Generated code should compile without requiring manual annotation.

Either:
Automatically add @OptIn(kotlin.time.ExperimentalTime::class) where needed, or
Provide an option to generate code compatible with stable kotlinx-datetime API.

Start by reproducing the Kotlin generator configuration with generatorName=kotlin, library=multiplatform, dateLibrary=kotlinx-datetime, and kotlinx-datetime:0.7.1. Inspect the generated LocalDateTime usages and determine which compatibility approach is intended. Done means the generated project compiles without requiring a manual ExperimentalTime opt-in.