[Context]: add context factory abstractions and creation helpers

[rian-be]

Summary

Add factory abstractions and creation helpers for building context instances in a consistent way.

Goal

Make context creation first class part of the package so application code can centralize context construction instead of scattering new calls and ad hoc factories across the codebase.

Problem

The current package focuses on accessing and executing within context, but context creation is still left entirely to application code. That works for simple cases, but it becomes repetitive and inconsistent when the same context shape needs to be created from different inputs such as requests, jobs, tenants, or authenticated users.

Without a dedicated factory abstraction, callers end up duplicating:

• context initialization logic
• ID generation
• creation timestamp handling
• normalization of incoming request data
• special case setup for trusted and read only flows

Scope

• Add context factory abstraction
• Add default factory helper for common context creation patterns
• Support creation from raw request data or application inputs
• Support creation of read-only snapshots where needed
• Keep creation helpers focused on construction, not execution
• Keep the API small enough to stay in the core package
• Add examples showing how factories fit into the current context workflow

Design Expectations

• Factory APIs should be minimal and explicit.
• Factories should return immutable or effectively immutable context instances.
• Context creation should stay separate from context activation.
• The factory layer should not become a policy engine or validation framework.

Acceptance Criteria

• The package exposes clear factory abstraction for context creation.
• Application code can centralize context construction behind a single interface.
• Factory helpers work cleanly with the existing manager and accessor APIs.
• The creation flow remains easy to reason about and does not add hidden runtime state.

Non Goals

• No governance layer.
• No persistence backend.
• No policy engine.
• No background orchestration.
• No ASP.NET specific binding layer.

Notes

This issue is meant to make context construction more structured before expanding into additional lifecycle or integration features.