Surface feedback + jobs paths in `vers agent-context`

[AlephNotation]

PRs #191 shipped vers agent-context (F11), vers feedback (F18 Phase A), and vers jobs (F14 Phase 1) in parallel. Because they were authored simultaneously, agent-context does not yet enumerate the feedback/jobs integrations or their environment variables.

Today

{
  "schema_version": "1",
  "feedback": {
    "local_path": "~/.vers/feedback.jsonl",
    "endpoint_configured": false
  },
  "available_profiles": []
}

Target

{
  "schema_version": "1",
  "feedback": {
    "local_path": "~/.vers/feedback.jsonl",
    "path_override_env": "VERS_FEEDBACK_PATH",
    "endpoint_env": "VERS_FEEDBACK_ENDPOINT",
    "endpoint_configured": false
  },
  "jobs": {
    "ledger_path": "~/.vers/jobs.jsonl",
    "dir_override_env": "VERS_JOBS_DIR"
  },
  "available_profiles": []
}

Why

An introspecting agent currently has no way to discover that vers jobs exists (well, it shows up under commands, but the ledger path is implicit) or that VERS_FEEDBACK_ENDPOINT is the upstream-routing env var. Surfacing both keeps the schema honest as the canonical single source of truth.

Scope

• Edit cmd/agent_context.go to add the jobs block and the env-var fields.
• Bump schema_version to "2" since this is an additive schema change agents may want to detect (or keep at "1" if we treat additions as backwards-compatible — pick one and document it).
• Update cmd/agent_context_test.go to assert the new fields.

Decision needed

Treat additive schema changes as schema_version bumps, or only bump on breaking changes? Prevailing convention in the article (Trevin) is to bump on breaking changes only. Recommend: stay at "1" for additive changes, bump only when a field is removed or its type changes.