RE: Finding aids
Right now, AtoM can only associate one generated or uploaded finding aid per archival unit (i.e. per hierarchy). Changing this would require development - and I think we'd also want to be careful about design, and think about how to make it clear to end users that further detailed finding aids may be available at lower levels.
In the meantime, one workaround you might consider would be uploading the lower-level finding aids as digital objects on the related series. Your custom finding aid uploaded at the fonds/collection level could indicate that more detailed file lists etc are available at the series level. AtoM will still attempt to index the finding aid text when uploaded as a digital object - though keep in mind that this workaround will affect the kinds of results you see when doing searches and filtering or faceting for finding aids and/or digital objects.
RE: PDFs, OCR and/or text layers, and AtoM indexing
You're right that AtoM currently will cut off the indexing of a text layer after a certain point. Please see this previous forum thread, where I've added an explanation:
In 2.6, this is essentially the same currently - AtoM stores the text layer in the property tables as a key/value pair. The field we're currently using is set to TEXT type in MySQL, which has a character limit of 65,535 characters or bytes by default. Remember as well that AtoM uses UTF-8 character encoding, in which characters can be 1-4 bytes, depending, so this isn't a 1:1 match between characters in the database and letters as we think of them. See also:
We haven't globally increased this to MEDIUMTEXT or larger because it could have significant impacts on search throughout AtoM - for example, if you have one hundred different 5,000 page finding aids then odds are some content in there is going to match almost every user query, and you're going to get a lot of noise in the search results, with those same 100 descriptions turning up all the time and it not being obvious from the record metadata why.
However, locally you could try modifying this field, and changing the type via MySQL. I would strongly recommend you make a backup of your data first, just in case there are unintended consequences, but you could assess how it impacts search and decide if it will better meet your needs.
You'll need to restart MySQL and PHP-FPM after, and you would also want to re-extract the text layer after, using this command-line task:
You would also want to rebuild the search index, so that newly extracted text shows up in search results.
Hope this helps!