How can I permanently remove replication by script if I only have access to the subscriber?
It sounds like what you're asking for is sp_removedbreplication, which you would run like:

EXEC sp_removedbreplication @dbname = 'MySubscriberDb';


From docs.microsoft.com:


  This stored procedure removes all replication objects ...on the
  subscription database on the Subscriber instance of SQL Server.
  Execute in the appropriate database, or if the execution is in the
  context of another database on the same instance, specify the database
  where the replication objects should be removed. This procedure does
  not remove objects from other databases, such as the distribution
  database.


That said, doing just this may not resolve your issue, depending on your configuration.

Option 1) Change your replication topology

I'd also recommend configuring your Distribution Agent to run as a pull subscription. This will enable you to disable the SQL Agent Jobs associated with loading any snapshots or transactions. Because the job is on your subscriber, you will be able to disable it, even when the publisher/distributor are offline. If/when the publisher/distributor comes online, you don't need to worry about transactions/snapshots being loaded to the subscriber, until you explicitly re-enable the Distribution Agent job. Note that if you do this, you would not need to use sp_removedbreplication.

Option 2) Change your replication topology another way

Is your distribution database on the same server as your primary? If you move your distribution database &amp; jobs to a dedicated distributor, then this provides similar benefit to Option 1. Additionally, you would have access to the distribution database in order to add/remove subscription information from the replication metadata.

Option 3) Revoke permissions

You could also evaluate the permissions in use by your Distribution Agents. By revoking permissions for a remote Distribution Agent, you can prevent the distribution agent from logging in to the database to re-establish replication.

Option 4) Is replication really the right choice?

While you're asking about replication, I'd challenge you to ask if replication is the right choice for your need. It sounds like you're using replication for High Availability / Disaster Recovery (HA/DR).  Replication isn't a great choice for HA/DR. You may find that Availability Groups make for a better HA/DR solution. They come with different challenges, but are specifically built to solve HA/DR needs, and ensure only a single writable primary in order to avoid this particular challenge.