The reason for your problem is that the original[with-attachment].pdf signing process creates an incremental update with cross-reference stream, while the source file has a cross-reference table. When adding incremental updates, the new cross-references must be of the same type as the old ones.
It is possible that this error is due to the fact that the process attaching attach.txt to the errors is also the same: it stores the file as a PDF with cross-reference, even if the original was a file with cross-reference, but at the same time leaves some elements from of the previous dictionary in the trailer of the new file. These labeled elements (which are not part of the trailer dictionary) probably make your signature process think that the source is already using a cross-reference stream.
Because this cross-reference style change between incremental updates is prohibited, Adobe Reader attempts to correct the document in memory. Such correction attempts often cause unforeseen ones. You want to save the changes to "original [with attachment] [signed]" before closing the warnings .
In the process of fixing the PDF, the entire PDF is reordered. This explicitly results in an invalid range of signature bytes.
original.pdf
%PDF-1.3 %âãÏÓ 11 0 obj <</Linearized 1/L 48987/O 13/E 37674/N 3/T 48682/H [ 480 178]>> endobj 25 0 obj <</DecodeParms<</Columns 4/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Index[11 22]/Info 10 0 R/Length 77/Prev 48683/Root 12 0 R/Size 33/Type/XRef/W[1 2 1]>>stream hÞbbd``b`jŒ â`–,õ@‚µÄb‰í±@Ä"Q{$¬rÄ‚MLŒ³€,F¬ÄÆK¿ Mi endstream endobj startxref 0 %%EOF 32 0 obj [.........] endobj 8 0 obj <</DecodeParms<</Columns 3/Predictor 12>>/Filter/FlateDecode/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]/Info 10 0 R/Length 50/Root 12 0 R/Size 11/Type/XRef/W[1 2 0]>>stream hÞbb```bœ¬ÅÄÀ°"‰A\š‰H³Îbbà)²'ñ5&F§Û@yF€ xi endstream endobj startxref 116 %%EOF
original [with application] .pdf
%PDF-1.3 %öäüß 1 0 obj [.........] endobj xref 0 33 0000000000 65535 f 0000000015 00000 n [...] 0000049667 00000 n 0000049737 00000 n trailer << /DecodeParms << /Columns 4 /Predictor 12 >> /Filter /FlateDecode /ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>] /Info 5 0 R /Length 77 /Root 1 0 R /Size 33 /Type /XRef /W [1 2 1] /Index [11 22] >> startxref 49755 %%EOF
original [with attachment] [signature] .pdf
%PDF-1.3 %öäüß 1 0 obj [....as above....] startxref 49755 %%EOF 1 0 obj [.........] endobj 37 0 obj << /ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>] /Info 5 0 R /Root 1 0 R /Prev 49755 /Type /XRef /Size 38 /Filter /FlateDecode /Index [1 1 6 1 33 4] /W [1 3 0] /Length 31 >> stream xœcd8ú'1&ˆ'áØ.F†ã¾ŒŒ±ù@| VÚ endstream endobj startxref 89569 %%EOF
Side note
Identity management: adding attachments adds an entire identifier . The signing process completely removes the original PDF ID and replaces it with a new one:
original.pdf
/ID[<321A6D6DCD0785E8E35BD4B13115140A><59793561FB914D408936FC170763541A>]
original [with attachment] .pdf
/ID [<321A6D6DCD0785E8E35BD4B13115140A> <59793561FB914D408936FC170763541A>]
original [signed] .pdf
/ID [<A9F7159B1E5D8285A68475689B750214> <A9F7159B1E5D8285A68475689B750214>]
original [with attachment] [signed] .pdf
/ID [<DC60F4419C05967B81D7F64090027D7F> <DC60F4419C05967B81D7F64090027D7F>]
Both approaches are erroneous, the processes that control the PDF and, therefore, create a new version, must contain the first record ID and replace only the second unique new one.