Add OIS support

[juanli16]

Why

The DCN recognizes a browser by the OPTABLE_OID cookie, which is third-party from a publisher page and dropped by Safari/ITP, Firefox ETP and Chrome's third-party cookie restrictions. When it is blocked the DCN sees a new device on every request, and a publisher cannot configure around it.

An OIS node also derives an identity for the browser, with the help of the device signals the SDK forwards in the sig param, and returns it on X-Optable-OID. The SDK never stored that ID, so nothing carried it from one visit to the next. This gives it a client-side memory.

What Changed

• lib/core/ois.ts (new): stores the derived OIS ID from the X-Optable-OID response header and replays it on subsequent requests. Limited to the endpoints where the DCN derives one
• lib/core/network.ts: attaches the header on send, reads it on receive, both filtered by the same path set.
• lib/core/storage.ts, lib/core/storage-keys.ts: cached under OPTABLE_OIS_<base64(host[/node])>. LocalStorage owns the key and exposes it through oisKey().
• demos: /vanilla/ois.html and /vanilla/nocookies/ois.html.

How to Test

A demo page is available at /vanilla/ois.html and /vanilla/nocookies/ois.html, showing the ID returned, its storage key, the decoded sig signals, and the X-Optable-OID header sent and received on each call.

Unit tests cover the behaviour: storing and replaying the ID, path filtering in both directions, consent gating, the change event, and the storage key format.

• Tested
• Docs updated

Notes

• Breaking change
• Requires release

[etiennelatendresse-optable]

We should probably consider adding the ois demo to demos/index.html. Its already added in the Dockerfile, but every other pages is in the index.html except OIS

[mosherBT]

We should probably consider adding the ois demo to demos/index.html. Its already added in the Dockerfile, but every other pages is in the index.html except OIS

Intentionally left out for now

[mosherBT]

/review

[pstm]

One thing to verify before merge: X-Optable-OID is a non-safelisted header, so it triggers a CORS preflight (OPTIONS) on every /identify, /profile, and /uid2/token call. This is the first custom request header the SDK sends on production traffic (X-Forwarded-For is test-only via mockedIP), so the node likely hasn't needed preflight support before.

Can you confirm the OIS node returns Access-Control-Allow-Headers: X-Optable-OID (preflight) and Access-Control-Expose-Headers: X-Optable-OID (response)? If not, these three calls fail once ois: true is set. It's opt-in, so blast radius is limited — but worth checking against a real node.

Rest of the JS/TS looks good.