No, there isn’t any way to prevent this.

I don’t really see it as a problem - if the user wants to sabotage how a library works, similar misconfigurations of IoC are equally possible for most other libraries.

I also do not understand where the problem lies, let me break it down to smaller considerations:

You use the interface and its implementation internally

So, you have places where you use IOurService and injecting something else might break things (although such practice is used for "extension points, like in ASP.NET).

To solve that, you should then stick to what you had - use concrete type instead to prevent "random injections of custom implementations". Or, if you want to keep interface, create another one internal interface IOurServiceInternal : IOurService, and register it and use it instead in your library.

The consumer use the interface in their own code (quite obvious :P )

Then the consumer speicfically writes in their code IOurService and expects it to work out of the box. This is only accomplished when you use your extension method to register the interface AddOurServices.

But, if the customer implements IOurService interface AND also overrides DI registration - IMO this is extremely intentional and the consumer REALLY WANTS to inject his own implementation (although, this would make using your library unreasonable). So I would not worry much about this case as well.

So, in turn, I would not overthink this and what you have is good.

Augmenting registartion of implentation of the interface

The other solution is to augment how you register yor service, so it resolves to OurService:

Considering such setup

CSHARPCopied
public interface IOurServiceLibraryConsumer
{
    void DoStuff();
}

public class OurServiceLibraryConsumer : IOurServiceLibraryConsumer
{
    private readonly IOurService _ourService;

    public OurServiceLibraryConsumer(IOurService ourService)
    {
        _ourService = ourService;
    }

    public void DoStuff()
    {
        //do things here
    }
}

you could register your dependencies like:

CSHARPCopied
builder.Services.AddScoped<IOurService, OurService>();
// Just to test
builder.Services.AddScoped<IOurService, ClientOurService>();
builder.Services.AddScoped<IOurServiceLibraryConsumer, OurServiceLibraryConsumer>(sp =>
{
    var ourServices = sp.GetRequiredService<IEnumerable<IOurService>>();
    var ourSerivce = ourServices.Cast<OurService>().First();
    return new OurServiceLibraryConsumer(ourSerivce);
});

Here's an approach. When your code is populating a service container for PRODUCTION use, inject a dummy class into the service container before calling .Build().

serviceCollection.AddSingleton();

DummyService doesn't have to have any methods. You just need it to show up in the service provider. Register it as singleton.

OK, now. In other services where you want to prevent mocking during production, inject an instance of IServiceProvider in the constructor. You will use this IServiceProvider instance to check to see if it can instantiate DummyService. You will use IServiceProvider.GetService(). If it's NULL, you know you're in a unit test. If it's not NULL, then you know you're running in production mode. If you're running in production mode, then you can do something to compare the types of current implementations, and if they don't match your production implementation, then throw an exception.

CSHARPCopied
interface ISomeNeededThing
{
}

class ProductionSomeNeededThing : ISomeNeededThing
{
}

class ConsumingService
{
    public ConsumingService(IServiceProvider serviceProvider, ISomeNeededThing snt)
    {
        bool isProductionMode = serviceProvider.GetService<DummyService>() != null;
        if (isProductionMode) {
            // check to see if it's the right implementation.  A mock will explode
            if (snt.GetType() != typeof(ProductionSomeNeededThing))
            {
                throw new NotSupportedException("Overriding ISomeNeededThing is not supported");
            }
        }
    }
}

I hope you get the humor here. This is an ultra-simplified approach. I would create a centralized service that does all the type checking. As long as your customer doesn't figure out how to inject the dummy service into the container, you're safe. The gist of my solution is that you have to do type checking and have a mechanism to know when you're running production code vs non-production code (unit tests)

Other than this, good luck.

You might try whether:

CSHARPCopied
public abstract class OurService
{
  internal OurService() {}
  // polymorphic methods here
}

internal sealed class OurServiceImpl : OurService
{
  // overrides here
}

does what you want, where OurService replaces the interface and OurServiceImpl is the type added by your registration code. Most mocking frameworks are perfectly capable of working past accessibility rules (the internal constructor), but this would be inconvenient to most regular code. OurServiceImpl would either be in the same assembly, or in an assembly nominated via [InternalsVisibleTo].

Important: "inconvenient" is not the same as "impossible". A sufficiently motivated actor can still bypass this via ref-emit.