Consolidate consumer-facing middleware into campus_python (caller-side SDK layer) #980

Parent context: #970 (campus-core carve-out) — the audience-based boundary discussion from the phase-1 review. Explicitly out of scope for the current session; parked until campus-core stabilizes.

Summary

Consolidate the consumer-facing middleware layer — the campus hooks and decorators that downstream apps (campus-classroom, campus-admin, campus-profile) wire into their Flask apps — into campus_python, the caller-side SDK, so that app authors never install a campus service to get middleware.

Current state (why this is a boundary problem)

• campus.audit.middleware (tracing init_app, init_journeys, rate gate, identity stamping) lives inside the audit service package. All three downstream apps import it, so installing any of them drags the entire audit service (routes, web UI, psycopg2). Measured: import campus.audit pulls psycopg2 via the service init.
• The middleware already speaks to services over the network only: it uses AuditClient (HTTP) and campus_python. It has no legitimate in-process dependency on any service implementation — its placement is historical, same pattern as the campus.common.http move (refactor(audit): move campus.common.http to campus.audit.http #976).
• Auth-flavored consumer glue (login_manager, session cookie, token re-acquisition) already lives in campus.flask_campus; campus.auth.middleware/ is an empty stub.
• The journeys feature is split across two packages: @flask_campus.journey decorator in flask_campus, init_journeys in audit.middleware, coordinating via the journey cookie.

Target

A single caller-side layer (campus_python) owning everything an app author touches:

• tracing init, journeys init + @journey, rate gate, identity stamping (from campus.audit.middleware)
• session/login glue and future auth decorators for downstream services (from campus.flask_campus)
• AuditClient + its HTTP client (from campus.audit.client / campus.audit.http) — auth/api are callers of audit; client code is caller-side by the same audience test

Protocol constants (journey cookie name, X-Journey-ID, EventLabel namespace, span tag keys) move to campus.common so consumer and service sides share vocabulary without importing each other.

campus.audit.middleware keeps a one-release deprecation re-export (init_app, init_journeys) while downstream app mains are flipped.

Open design decisions (settle when this starts)

1. Repo placement: campus_python (separate repo, independent versioning — apps already pin it) vs an in-monorepo consumer package (flask_campus). The direction recorded here is campus_python; the tradeoff is cross-repo coordination for the moves below.
2. Flask dependency: middleware requires flask; SDK would need a [flask] extra (or a sibling distribution) so non-Flask SDK consumers (CLI, scripts) don't gain flask.
3. HttpHeader / webauth models: the harness and middleware import campus.webauth.models (future campus-core); SDK-owned middleware needs these available without campus-suite — likely promote the header model into common or duplicate a minimal version SDK-side.
4. Sequencing vs phase 3: consumer consolidation changes what campus-suite contains; do it after campus-core is stable (per Carve out campus-core: phased separation of shared layers from service imports #970 ordering), possibly as its own phase rather than a rider on the distribution split.

Boundary rules once done (extends the #977 contract tests)

• The consumer layer never imports campus.auth / campus.api / campus.audit / campus.yapper (currently flask_campus sits in the contract test's SERVICE_LAYERS set — it changes sides).
• Services may import the consumer layer (they are Flask apps using a library); never the reverse.