SearchApiViewsQuery::get_result_wrappers(): Do not use views row_index as entity_id.

We set the Views result ourselves, so I'm pretty sure we can guarantee

No we can't - especially if you use some advanced use cases.
That's why I explicitly linked to views_content_plugin_style_ctools_context (see line 31-34) in #1350814: EntityFieldHandlerHelper should not use views row_index as entity_id.
This is what you can see there:

31 // Some engines like solr key results on ids, but rendering really expects
32 // things to be keyed exclusively by row index. Using array_values()
33 // guarantees that.
34 $this->view->result = array_values($this->view->result);

This means if I use this ctools plugin to output my content, it will actively reset the row_index.
And even if this behaviour could be interpreted as somehow special, it doesn't violate any definition - because there's no definition that row_index has to be a special value at all.
The provided patch would make the views integration immune from such changes.
Is there any reason why not to make the code more solid? Especially if there are no drawbacks of any kind, which seems to be the case here.

Thank you very much for committing this :)