JSON-LD: a malformed IRI is silently dropped — `checking`/`strict` and the `ErrorHandler` never sees it

### Version

6.1 / main

### What happened?

A JSON-LD document with a malformed IRI loses an entire node, and the parse reports success.
No warning and no error reaches `ErrorHandler`, and neither `checking(true)` nor `strict(true)` changes this.

Jena delegates JSON-LD parsing to Titanium.
Titanium validates uris itself and when it rejects one, it discards the node, logs it and does not propagate it.
So the term is gone and Jena's own IRI checking can't catch it.

At best even if all iris are valid, it also means than each of them is validated twice.
As Jena operates at the RDF level, it makes more sense to keep it as the single source of truth for those checks.

The fix is simple:
If it is not defined upstream, `TitaniumJsonLdOptions.get` always takes Titanium's defaults, which include `uriValidation = Full`.
ALways setting Titanium's uri validation policy to ` None` disables this Titanium validation allowing Jena's downstream checks to properly apply its own validation.

Happy to submit a PR if we agree on the approach.

### Are you interested in making a pull request?

Yes

Start at the TitaniumJsonLdOptions.get entry point and trace how Titanium URI validation interacts with Jena's ErrorHandler and checking/strict options. Add regression coverage for a malformed IRI, confirming the node is not silently dropped and that Jena reports the problem while valid IRIs still parse successfully.

Written by the indexing model from the issue text.