Removed covers should not be auto-reimported

Cover imports are weirdly aggressive. If I open a coverless edition, frequently a cover is instantly imported. If I remove that cover and add an ocaid (which has a real cover), the deleted cover is reimported and I have to remove it again.

The cover imports do not appear as cover edits in the history.

Evidence / Screenshot (if possible)

Relevant url?

https://openlibrary.org/books/OL46535237M/Merry_Christmas_Alex_Cross?m=history

Steps to Reproduce

1. Go to ...an edition with no cover.
2. Do ...Click edit to see if a cover is auto-imported. If so, remove the cover and save it. See if the cover was immediately re-imported on save.

• Actual: Removed cover was immediately reimported on saving the new edits.
• Expected: Removed cover should not be reimported. In this particular case, since I added an ocaid, importing the item's actual cover would have been appropriate and welcome.

Details

• Logged in (Y/N)?
• Browser type/version?
• Operating system?
• Environment (prod/dev/local)? prod

Proposal & Constraints

Covers imported from a retailer are frequently be incorrect or low-quality. If a human editor removes the imported cover, it should not be reimported.

Ideally, when an item has an ocaid added, it would be useful if the cover of the actual item were imported (rather than a stock image from a retailer).

Related files

Stakeholders

@mekarpeles

Start by reproducing the behavior on the linked Open Library edition and review its history while removing a cover and adding an ocaid. Trace the cover-import and save flow from there; done means a manually removed cover is not reimported, while an appropriate cover can still be imported after adding an ocaid.