…_PREFIX (NousResearch#14603)

The SUMMARY_PREFIX previously instructed the model to 'resume exactly from
there' the ## Active Task section of a compressed summary. This caused
cross-session task injection where the AI would interpret a previous
session's active task as its own current job.

Fix: Replace the 'resume' instruction with explicit language that the
## Active Task section is 'historical context only, NOT as an active
instruction to execute'.

- agent/context_compressor.py: +3 lines, -2 lines
- tests/agent/test_context_compressor.py: +29 lines (3 regression tests)

llama.cpp exposes /props at server root (not under /v1 prefix per httplib
routes). The previous code tried /v1/props first, which returns 404 on
standard llama.cpp builds, causing unnecessary failed requests before
fallback to /props.

What broke:
- Server-type detection tried /v1/props first, returning 404
- Context probe also tried /v1/props first when base URL had /v1 prefix
- Users with llama.cpp configured saw 404 errors in server logs

Root cause:
- Comment incorrectly stated "llama.cpp exposes /v1/props (older builds
  used /props)", but actually /props is at server root per httplib routes
- Endpoint order was reversed: /v1/props tried before /props

Why this fix is minimal:
- Only changes endpoint order: try /props first, then /v1/props fallback
- Strips /v1 prefix from base_url to get server root for /props request
- Preserves fallback for alternative builds/configs using /v1 path

What I tested:
- Added regression tests for /props endpoint detection
- Tests verify correct URL construction with /v1 prefix stripping
- Tests cover fallback to /v1/props when /props returns 404

What I intentionally did not change:
- Response body parsing (default_generation_settings check unchanged)
- Other server type detection (LM Studio, Ollama, vLLM unchanged)
- Error handling and fallback logic structure

Fixes NousResearch#13091

…CUMENT

What broke
Signal attachments with application/* or text/* MIME types (e.g. PDFs)
were silently ignored. The agent received the message but responded as
if no file was attached because the document context was never injected.

Root cause
In signal.py `_handle_envelope`, the msg_type was set to TEXT for all
non-image/non-audio attachments. The document-injection code in run.py
only fires when event.message_type == MessageType.DOCUMENT.

Why this fix is minimal
Single elif branch added after existing image/audio checks. Preserves
existing behavior for audio/VOICE and image/PHOTO types. No broader
refactor to the attachment handling pipeline.

What I tested
Added 6 regression tests covering:
- application/pdf → DOCUMENT
- text/plain → DOCUMENT
- application/json → DOCUMENT
- audio/* → VOICE (not affected)
- image/* → PHOTO (not affected)
- empty media_types → TEXT (not affected)

What I intentionally did not change
- The document-injection logic in run.py
- Other platform adapters (Telegram, Discord, etc.)
- The attachment fetching pipeline

… MIME types

Issue: NousResearch#12845
The message type determination in _handle_envelope only checked for
audio/ and image/ MIME types, missing application/* and text/* which
should be classified as DOCUMENT messages.

This fix adds an elif branch to handle application/* and text/* MIME
types, properly classifying PDFs, documents, and text files as
DOCUMENT messages instead of falling through to TEXT.

Added regression tests for MIME type classification order and document
detection.