Currently, the span id included in the traceresponse header is a child-id, and refers to the span-id of server operation. This only enables linking the browser span to the server, and not help with establishing a parent-child relationship in a single trace.
While linked traces makes sense if we consider browser context to be outside the server network trust boundary, there's another perspective that having a single trace view including the browser span brings simplicity to user experience, especially when both the browser and server apps belong to the same organization.