fix: LEAP-1004: Show prediction with selected project.model_version in QuickView

[niklub]

In "QuickView" mode, user now sees the prelabeled data from the prediction based on selected model version.
If prediction from this model is not presented it fallbacks to old behavior and uses the first prediction.

Model version selected:

Correct prediction is shown first:

PR fulfills these requirements

• Tests for the changes have been added/updated (for bug fixes/features)
• Docs have been added/updated (for bug fixes/features)
• Best efforts were made to ensure docs/code are concise and coherent (checked for spelling/grammatical errors, commented out code, debug logs etc.)
• Self-reviewed and ran all changes on a local instance (for bug fixes/features)

Change has impacts in these area(s)

• Product design
• Backend (Database)
• Backend (API)
• Frontend

[netlify]

✅ Deploy Preview for heartex-docs canceled.

Name	Link
🔨 Latest commit	a8abb14
🔍 Latest deploy log	https://app.netlify.com/sites/heartex-docs/deploys/661e73f754c77000089429a7

[netlify]

✅ Deploy Preview for label-studio-docs-new-theme canceled.

Name	Link
🔨 Latest commit	a8abb14
🔍 Latest deploy log	https://app.netlify.com/sites/label-studio-docs-new-theme/deploys/661e73f744c9a9000965d176

[deppp]

Why do we think this is a correct behavior? That should be an EXPLICIT user action to select what predictions should be used?

[niklub]

/git merge develop

Workflow run
Successfully merged: 327 files changed, 70 insertions(+), 14 deletions(-)

[niklub]

Why do we think this is a correct behavior? That should be an EXPLICIT user action to select what predictions should be used?

In the current implementation, the only explicit user action is to set the model version in project settings, which produces the bug fixed in this PR.

Two alternatives that could be better from UX perspective:

• either let the user create annotation from prediction manually, without pre-initializing it (downside: it can break existing QuickView labeling flow without or with a single prediction, or introduce inconsistency)
• or let the user copy predictions into the draft annotation (downside: this tool has to be implemented)

Is there any other scenario that can better address the problem?

Anyway, this PR obviously fixes an incorrect behavior, and we can address future enhancements in the next ones