Online page restore hitting 1000 limit
The standard procedure would be to:


Obtain the page IDs that have to be restored.
Start a page restore with a full database.
Apply the most recent differential backup.
Apply subsequent log backups.
Create new log backup.
Restore the new lob backup.


After the new log backup has been applied, the page restore is completed and the pages are then usable.

Example Restore

RESTORE DATABASE &lt;database&gt; PAGE='1:57, 1:202, 1:916, 1:1016'  
   FROM &lt;file_backup_of_file_B&gt;   
   WITH NORECOVERY;  
RESTORE LOG &lt;database&gt; FROM &lt;log_backup&gt;   
   WITH NORECOVERY;  
RESTORE LOG &lt;database&gt; FROM &lt;log_backup&gt;   
   WITH NORECOVERY;   
BACKUP LOG &lt;database&gt; TO &lt;new_log_backup&gt;;   
RESTORE LOG &lt;database&gt; FROM &lt;new_log_backup&gt; WITH RECOVERY;  
GO  


Reference: Restore Pages (SQL Server) (Microsoft Docs)
Reference: RESTORE Statements (Transact-SQL) (Microsoft Docs)    

However, you have holes in your TLOG backups, and restoring with above procedure might bring your database back into a state in time that you do not desire.



You are in a complicated situation. 


Your database has corrupt pages and your company is constantly adding new data to a database with issues. This could result in a total downtime of the database. Do you want to risk that? 
Somebody is going to be held responsible and the more you try to fix it, the more management might be inclined to decide that you might be that person in the end. Do you want to risk that?
You are putting yourself in a difficult situation by taking on a role that you were not employed for. You are trying to achieve something that neither your company DBAs nor your external consultant were capable of. While it may seem to be a noble gesture, you are putting yourself at risk. You might have "implicitly promised" something that you will never be able to fulfil. Do you want to risk that?
When somebody working with the database queries data that is corrupt, they are possibly going to receive an error message. Daily work is already being impacted. The longer you wait with the inevitable the more productivity will be impacted. Do you want to risk that? (This question could also be raised with management)
Your company's backup procedure seems to be faulty (otherwise how would TLOG backups be missing?) and you are still running your production database as if there were no issues. Do you want to risk that?


The best recommendation I can give you is to halt production and call Microsoft!
Or at least call Microsoft and possibly halt production. 

While my writing may seem overly cautious and slightly dramatised from your perspective, I can personally relate to an experience as DBA where data was lost in a similar situation. We only lost half a days data, but we had to re-synchronise a lot of data with surrounding systems.

The longer you wait the more expensive recovery could become.



As for the limitation on page restores, here a quote from the official documentation:


  The maximum number of pages that can be restored into any single file in a restore sequence is 1000. However, if you have more than a small number of damaged pages in a file, consider restoring the whole file instead of the pages.


(emphasis mine)  

Reference: RESTORE Statements - Arguments (Transact-SQL) (Microsoft Docs)  



When all is back to normal, the DBAs and/or external consultants might want to consider implementing a different backup/restore policy/procedure for your database. As it has to be up 7x24 you can't risk having a backup procedure that doesn't provide adequate restore capabilities for any situation.