OK.  for some reason the most important part of the link was truncated.

https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25CSP.BinaryStream

I hope it doesn't hide again.

The basic mistake happens here the definition of Request 
https://docs.intersystems.com/latest/csp/documatic/%25CSP.Documatic.cls?PAGE=CLASS&LIBRARY=%25SYS&CLASSNAME=%25CSP.Request

And you are right. %CSP.Stream has no Read method because  ContentType tells you the true object . 
As in the example:

It could have been %CSP.CharacterStream as well.

Both extend over some steps %GlobalStreamAdaptor which have all the READ, WRITE, ....methods

Just reading docs and not checking inherited methods (e.g. in Studio) is mostly misleading.

Just adding CACHESYS to mirror could be a deadly exercise

Who then is primary? Me or my Mirror?

But to achieve your goal you may have an additional DB. Let's name it SYSMIRROR
And now you use global / subscript level mapping to place the common information there.
e.g. ^SYS("Security") or parts of it ("RolesD","UsersD", ..)  whatever you think you need.
I never tried it but it could not see a contradiction.

For better synchronization and uniqueness, I'd personally prefer to have this SYSMIRROR accessed over ECP while holding a local copy of SYSMIRROR for backup /  failover

YES it is possible.

- see your sub_query first working 
- just custom_view seems to miss the typical dot in table and view names 

Views are just a kind of shortcut to a query formula.

 in namespace SAMPLES you could do this

select Home_City, DOB, name,
(select Name from sample.personview sub where sub.DOB=main.DOB ) SubName
 from Sample.Person main

The example doesn't make much sense but it shows that this works

Anyhow, why don't you just use a JOIN  like this?

select Home_City,main.DOB, main.name, sub.name
from Sample
.Person main
left outer join sample.personview sub on
sub.DOB=main.DOB

or in your case 

select    MsgId,   FileName, ReportName
from main_table LEFT OUTER JOIN   custom_view
ON     MsgId = ReportId

Again: both table name and view name look odd to me

 

for pure object access, you have a getter and a setter method.  no magic

if also want to use it for SQL
- you need SqlComputed code. This will also replace your (object)Getter.

- to set your local variable also by INSERT or UPDATE you need to add  UPDATE and INSERT Trigger code.

example;

Class DC.Setter Extends %Persistent [ Not ProcedureBlock ]
{
Property DUZ As %String [ Calculated, SqlComputed, SqlColumnNumber = 2
,
       SqlComputeCode = {set {*} = DUZ(2)}  ];

// for settig object property
Method DUZSet(Arg As %String) As %Status [ ServerOnly = 1 ]
 set DUZ(2)=Arg  Quit $$$OK   }

Trigger UpdTrigger [ Event = UPDATE ]
{ set DUZ(2)
= %d(2) ,%ok=1 }
Trigger InsTrigger [ Event = INSERT ]
set DUZ(2)=
  %d(2) ,%ok=1 }

--

To anticipate critics:
Some people may say it's dirty coding.  YES !! But it works.

as a first suggestion, I would create a setter and getter method for this property that handles DUZ(2) in both directions.
If you add any property by the wizard it shows you the exact naming of the methods.
this property then goes in the first position of the IDkey
be aware of ProcedureBlock to have always access to your   DUZ(2)  or name it %DUZ(2) as hack