Add the 51Did creator context web example

[jwrosewell]

The 51Did creator context feature for Rust, in two parts.

1. The creator context web example

Adds the web example under examples/fodid-examples, beside the existing example crates. Every 51Did the 51Degrees cloud issues carries a creator context, which binds the identifier to the browser and connection it was created on. The example serves a page that creates a 51Did from the browser, verifies it from the browser with verify-full (which answers only with a sealed result the browser cannot read or forge), and hands the sealed result to the example's own server, whose /redeem route redeems it with the licence key that only the server holds. Opening the page's copy link in a different browser shows the creator context failing to validate while the signature still verifies, which is the demonstration.

The same commit lets every cloud example in this repository be pointed at another host through the 51DEGREES_CLOUD_ENDPOINT environment variable the READMEs describe.

2. The cloud client in the fodid crate, used by the example

The fodid crate gains a cloud client behind an opt-in cloud feature, in a new client module, so a server that checks a 51Did never writes HTTP or key handling of its own. The feature is opt-in so the reader alone pulls in no HTTP stack and the crate keeps building for WebAssembly consumers.

New surface in fodid:

• FodId::from_base64 now accepts both base64 alphabets, the standard one with padding as the cloud issues it and the URL-safe one (- and _, padding optional) a page uses when it puts the identifier in a link. Both decode to the same envelope.
• FodId::as_base64_url(), the URL-safe form without padding, for putting an identifier in a URL.
• FodId::date_minutes(), the envelope date as the count of minutes since 2020-01-01T00:00:00Z, which is how the wire format stores it.
• FodId::license_id() is documented as the field's raw value, because on an identifier carrying a creator context the four bytes hold an encrypted value that only 51Degrees can turn back into a licence identifier.

New surface in fodid::client (with the cloud feature):

• DidClient, built with DidClient::builder(resource_key) plus an optional licence_key, endpoint (defaulting to the public cloud or 51DEGREES_CLOUD_ENDPOINT, with a trailing slash normalised) and transport.
• public_keys() fetches the signing public keys once and caches them for a day, and public_key_for(&fod_id) picks the key in force when the identifier was created, refetching once when the held list does not cover the date. A required refresh failure is returned because the held schedule may not contain the correct key.
• verify_signature(&fod_id) checks the signature offline against that key (and a neighbouring key within a small tolerance of a boundary, never every earlier key), with verify_signature_detailed telling an invalid signature from a date no held key covers.
• verify(&fod_id_or_string) checks through the cloud's verify endpoint. The identifier is sent under both parameter names, 51did and owid, so the request works with hosts that read either parameter. Hosts that recognise both prefer 51did and keep owid as a compatibility alias.
• redeem(&fod_id_or_string, result, challenge) posts the sealed result with the licence key and returns a typed RedeemResult carrying context (Verified, Mismatch, NoContext, NotCheckable, Expired, Replayed, Unreadable, Unconfirmed), signature, factors when the cloud sent them, verified_at, seconds_since_verified, the HTTP status and the raw body. A 400 raises ClientError::InvalidIdentifier, a 404 raises ClientError::NotSupported, any other status ClientError::Http and no answer at all ClientError::Transport.
• Transport, the HTTP trait the client sends through, with UreqTransport as the default and a way for tests to inject their own.

Credentials never reach a query string. The resource key travels in the route of the key and verify calls and in the form body of the redeem POST, and the licence key only in that form body. Every request sends a User-Agent naming the crate and its version.

The example's /redeem route (the redeem_with function in examples/fodid-examples/src/bin/fodid-web-creator-context.rs) now builds one DidClient at start-up, parses the incoming 51Did with FodId::from_base64, checks its signature offline, redeems through the client, and answers the page with the cloud's status and a JSON body in the cloud's own shape plus one extra field, serverSignature. The page is byte-identical to the page in the other client examples. Its relative stylesheet URL is served from the shared Rust asset. The example depends on the fodid crate from this repository with the cloud feature, so this pull request tests the branch, and its reqwest dependency goes because the client replaces it.

The fodid README gains a "Verifying on your server" section covering parse, offline verify, cloud verify and redeem in that order, and says that verify-context and verify-full are browser calls because the context describes the browser's own connection. The example README's "copy these lines into your server" section shows the client calls.

The pull request workflow now also tests and lints the fodid crate with every feature on, because the workspace commands leave the opt-in feature off, and runs the client's live tests alongside the existing ones when a resource key is available.

Tests

• cargo test -p fodid --all-features: 24 passed and 1 ignored before, 77 passed and 3 ignored after (5 unit, 43 client, 28 reader, 1 doctest, with the 3 ignored being the live cloud tests that need a resource key).
• The example crate (cargo test --config source.toml -p fodid-examples in examples/): 4 passed before, 8 passed after, including one that drives /redeem with a fake cloud and checks the answer's shape and the serverSignature field.
• The full examples workspace (cargo test --config source.toml in examples/): 85 passed and 11 ignored before, 89 passed and 11 ignored after.
• cargo clippy --all-targets --all-features -- -D warnings, cargo clippy -p fodid --all-targets -- -D warnings, cargo doc and cargo fmt --all --check are clean.

The unit tests use an injected transport and a real key pair, so no network is used. The live tests are #[ignore]d, as the existing live test is, and skip in a plain run.

What the reader accepts, and the client's guard

The reader has no upper bound. A payload must be at least the base length for its identifier type, and anything beyond that base is a creator context section whose exact lengths belong to the cloud, so a longer payload is accepted and left to the cloud to judge. The creator domain is a deployment parameter as well, so a self-hosted container may sign with a longer domain and the identifiers it issues still parse. Both matter because the service deliberately accepts a context section of a version it does not implement, which is what keeps an older verifier working when a newer version ships.

DidClient keeps one guard against obviously malformed input, refusing an encoded value far longer than any identifier before it decodes anything, fetches a key or calls the cloud. The bound is arbitrary and generous on purpose and says nothing about how long a 51Did is. It sits at the request boundary, so a third party implementation of DidInput passes through it too.

Both the reader and the client strip leading and trailing whitespace from an encoded identifier before measuring it or converting its alphabet, and work the base64 padding out from the stripped length, so a value carrying a newline or a stray space from a link, a header or a file reads back to the same envelope as the clean form.

Public method signatures are unchanged, and general cloud response bodies are not capped.