[Fix][scala-sttp] Register JSON value type in importMapping to avoid model-package-prefixed import

[nikhilsu]

Summary

The scala-sttp generator emits a broken import in the generated API file when an endpoint returns a free-form
type: object (or AnyType) schema:

// Before
import org.openapitools.client.model.io.circe.Json // <- does not exist; compile fails

processOpts() registers the fully-qualified io.circe.Json (or org.json4s.JValue) in typeMapping for object /AnyType, but does not register a corresponding entry in importMapping. As a result, DefaultGenerator.getAllImportsMappings()falls through toDefaultCodegen.toModelImport()`, which blindly prepends the configured model package to the type name.

Fix

Register the simple class name in typeMapping (so generated code uses Json / JValue inline) and the fully-qualified name in importMapping (so the import resolves correctly to the library, not the model package):

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details
  about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project
  and update samples:

  ./mvnw clean package || exit
  ./bin/generate-samples.sh ./bin/configs/*.yaml || exit
  ./bin/utils/export_docs_generators.sh || exit
  

  (For Windows users, please run the script in WSL)
  Commit all changed files.
  This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master.
  These must match the expectations made by your contribution.
  You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example
  ./bin/generate-samples.sh bin/configs/java*.
  IMPORTANT: Do NOT purge/delete any folders/files (e.g. tests) when regenerating the samples as manually written
  tests may be removed.
• File the PR against the correct branch:
  master (upcoming 7.x.0 minor release - breaking changes with fallbacks), 8.0.x (breaking changes without
  fallbacks)
• If your PR solves a reported issue, reference it
  using GitHub's linking syntax (
  e.g., having "fixes #123" present in the PR description)
• If your PR is targeting a particular programming language, @mention
  the technical committee
  members, so they are more likely to review the pull request.

[nikhilsu]

cc @clasnake (2017/07), @shijinkui (2018/01), @ramzimaalej (2018/03), @chameleon82 (2020/03), @Bouillie (2020/04) @Fish86 (2023/06)

[nikhilsu]

@wing328

[cubic-dev-ai]

No issues found across 4 files