I'll start off by asking you to ask your why you're trying to do this. Put yourself in your users place. How would you feel if you used a package, wanted to make a small modification to how it works in your project, but found you had to create extra files and use pre-defined extensibility points and being unable to make a modification if the package author didn't provide a certain extensibility that you want to use? Also consider that with HTTP 1.x, the time to establish a new TCP/HTTP connection is high compared to making a css or js file a bit larger, so end-users typically have better experience when the web app bundles everything into a single file, but your package is trying to force the app to use multiple js and css files.
If you still want to prevent developers using your package from modifying the files from your package, you won't be able to use NuGet's content or contentFiles features. content, used when a package is referenced with packages.config are copied to the destination project on package install, and the developer certainly can make modifications to files in their project directory. contentFiles are used when a project reference the package with PackageReference. It doesn't copy the files the project directory, but the files might still appear in Solution Explorer, which make it easy for the user to open and modify (even if they don't realise it will affect all projects/solutions on the computer, and the changes won't be part of their project's source control). Since contentFiles works using MSBuild items, and MSBuild is a build-time tool, trying to distribute static files (js and css) this way probably gives developers a bad experience because it the files won't be available to ASP.NET during debugging, only after publishing.
One option is to use NuGet's support for MSBuild .props and .targets files. Instead of putting your js and css files in the NuGet content or contentFiles directories, you put it elsewhere (perhaps in the build directory, since that's where your .props and .targets file must be), and you have MSBuild instructions to add your files to the build, but with the Visible="false" attribute, so it doesn't appear in Solution Explorer. However, since the file won't be on disk in the project's directory, it may give the developer a poor development experience since the static file handler won't be able to find/serve the files during debugging and will only be there when the web app is published, which is the same issue that NuGet contentFiles has.
Another option is don't distribute the resources in your NuGet package. Put them on your website or on a CDN, and have your HTML load them from there. Developers can't modify files that are not on servers they control, but if they can modify the URL that your HTML loads these resources from, they can just copy your js and css to their project and use and modify them anyway. The website that you host those files is also a risk to anyone using your package, since if the web app's website works, but your css and js files can't be downloaded, then the web app may not work. If your package is something that's useful for internal enterprise apps, then your package may not work for them if their security policy is to forbid any external network access.
Yet another option is to embed the resources in your .NET assembly. This means you'll no longer be able to use ASP.NET's static file handler. If your package isn't already some kind of middleware or handler that needs to be registered on app startup, then you'll need to create methods for package users to call, and your code will add routes to the router for your css and js files, and provider a handler to return the relevant files when the route is matched. For small, static files you probably don't care about supporting HTTP range requests, If-Modified-Since and other HTTP features that browsers use, but if you want to do things "right", there's a fair amount of work needed just because you don't want the files to be on-disk and therefore editable.
I'm sure a creative person can think of more ways to ensure that someone using your package can't edit the resources your package needs to work, but I again ask you think think about why you're trying to do it. Does it help the developer using your package, or are you just trying to control them? Imagine different ways that someone may want to use your package, some of these ways will be different to how you intend your package to be used. Does the way you prevent editing of resources make it unreasonably difficult for the developer to use your package how they want to use it? What, exactly, is the risk/harm you're trying to avoid by preventing a developer from editing the js or css files distributed by your package? Are there different ways to minimise the risk and/or harm, other than preventing them from editing the files?
