det/facade: a RETURN TRANSID COMMAREA crosses to the next task as its DTO only -- a numeric field holding spaces comes back as digits #4817

Found while fixing #4806 (a LINK / XCTL COMMAREA through a DTO lost bytes the DTO cannot decode; that fix passes the bytes beside the DTO, so a det program takes them as they are).

Gap. A level-1 RETURN TRANSID ... COMMAREA still carries the COMMAREA as the DTO only (CicsTask.returnTransid -> returnedArea -> returned(type) / the facade's handleTransaction answer, #4343 / #4449). A field the DTO cannot decode -- a numeric DISPLAY field holding spaces, as CBSA's front ends leave in their RETURN COMMAREA -- is read as a number (spaces: -16) and, when the next request brings that DTO back, the next task's DFHCOMMAREA holds digits where the previous task left spaces.

IBM. RETURN TRANSID COMMAREA passes the bytes to the next task of the pseudo-conversation (a copy); every byte arrives as it was, invalid numeric content included.

Scope. The equivalence harness does not observe it: each scenario gives its own COMMAREA (the RETURN's is compared as an event). It is the deployed region / facade path. Related: #4695 (the facade gets byte[] for a RETURN LENGTH past the DTO).

Done when. The deployed pseudo-conversation keeps the bytes (e.g. a byte-carrying COMMAREA beside the DTO, or the DTO keeping the bytes it cannot decode), or such a COMMAREA is refused by name at the facade, never silently changed.

Part of #4270.