CLI: surface PR observation in `ao session get`

[harshitsinghbhandari]

None of the shipped CLI commands (ao session ls, ao session get, ao project ls, ao project get) read from the pr, pr_checks, or pr_review_threads tables. There is no way for a user to ask "what does the daemon think the PR for session X looks like?" without dropping into SQLite directly. This is a debuggability and UX gap that will get worse as the SCM observer becomes the source of truth for PR state.

Acceptance

• ao session get <id> includes a pr section when a pr row exists for the session, showing at minimum: URL, number, state, CI summary, review decision, mergeability, head SHA, observed_at, ci_observed_at, review_observed_at.
• If multiple PRs are claimed by one session, list them in priority order (open before merged/closed, mirroring chooseKnownPR in backend/internal/observe/scm/observer.go:478-493).
• --json output carries the same fields under a stable key (prs: [...]).
• The HTTP route(s) that back this surface the same shape — reuse service/session.NewWithDeps.PRClaimer and the existing ListPRsBySession path PR feat: ao session claim-pr + spawn --claim-pr wiring #101 introduces.
• Failing checks include LogTail only in --json; the default human output should summarize ("3 of 5 checks failing: build, lint, test") to keep ao session get scannable.
• Unit + CLI tests covering: no PR, one PR, multiple PRs, failing CI with log tail, merged PR.

Why now

Once #108 ships, the observer will actually be writing meaningful rows. Without this command the only way to verify it is hand-rolling SQL queries. This is also the natural place to add --watch later when #110 (SSE) lands.

Related

• Builds on PR feat: ao session claim-pr + spawn --claim-pr wiring #101's GET /api/v1/sessions/{id}/pr route.
• Stays consistent with the existing ao session get output style in backend/internal/cli/session.go.