The cause of your issue is that the process of signing original[with-attachment].pdf creates an incremental update with a 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 quite possible that this error is due to the process attaching attach.txt misbehaving a bit, too: it stores the file as a PDF with a cross reference table even though the original was a file with a cross reference stream, but at the same time leaves some elements from the former cross reference dictionary in the trailer of the new file. These left-over elements (which do not belong in a trailer dictionary) probably make your signing process think the source already uses a cross reference stream.
As this change of cross reference style between incremental updates is forbidden, the Adobe Reader tries to fix the document in memory. Such attempts to fix often give rise to unexpected Do you want to save changes to "original[with-attachment][signed]" before closing? warnings.
In the course of fixing the PDF, the whole PDF is rearranged. This obviously causes that signature byte range is invalid.
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-attachment].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][signed].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
A side remark
ID management: Your process adding attachments keeps the whole ID. Your signing process drops the whole original ID of the PDF 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 wrong, processes manipulating a PDF and, therefore, creating a new version of it, shall keep the first ID entry and replace only the second one with a unique new one.
