test(mcp): mem_context budget follow-ups from the #1039 review (min-floor test, schema fallback doc, ordering note)

[danielgap]

📋 Pre-flight Checks

• I have searched existing issues and this is not a duplicate
• I understand this issue needs status:approved before a PR can be opened

🔍 Problem Description

The native review of PR #1074 (lineage review-c5d66f2dc210046d, reliability lens) approved the change with three advisory suggestions recorded as separate later work. They are small quality gaps in the new mem_context budget surface, none blocking:

1. Min-floor boundary untested: memContextMaxBytes now falls back to the 16 KiB default for sub-integer positives, but the smallest valid explicit budget, max_bytes=1, has no test. A future refactor of the n < 1 guard could regress the boundary silently (internal/mcp/mcp.go, the resolver and its guard).
2. Schema description omits the fallback: the tool description for max_bytes documents the default and the 64 KiB clamp but not that invalid input (mistyped, non-positive, NaN, sub-integer) falls back to the default budget. A caller reading only the schema has no way to know a bad value is safe rather than an error.
3. Pinned-order tiebreak assumption undocumented: the budget tests assert newest-first pinned ordering (pinned-119 down to pinned-100) based on pinnedObservationsLimit ordering by datetime(created_at) DESC, id DESC. The test comments explain it, but the assumption depends on insert-order IDs; a future ordering change in the store would break the budget tests in a way that points at the wrong layer.

💡 Proposed Solution

One small follow-up PR touching only internal/mcp:

• Add a test case asserting max_bytes=1.0 renders an exactly 1-byte budget (or the closest renderable prefix) and stays valid UTF-8.
• Extend the max_bytes schema description with one sentence documenting the invalid-input fallback.
• Add a comment in internal/mcp/context_budget_test.go (or a store-level note) naming the ordering dependency explicitly, so a store ordering change explains the failure at the right layer.

📦 Affected Area

MCP Server (tools, transport)

🔄 Alternatives Considered

• Folding these into PR perf(mcp): cap mem_context output budget (#1039) #1074 itself: they arrived as post-approval advisories; reopening the merged-scope branch would churn a reviewed candidate for test/doc polish.
• Dropping them: items 1 and 2 harden exactly the guarantee perf(mcp): cap mem_context tool output (complete the #1012 bounding on the MCP path) #1039 exists for (never unbounded, honest schema), and item 3 prevents a misleading future failure.

📎 Additional Context

• Source: advisory findings of the approved review of perf(mcp): cap mem_context tool output (complete the #1012 bounding on the MCP path) #1039 (R3-maxbytes-min-floor-untested, R3-maxbytes-schema-doc-fallback, R3-pinned-order-tiebreak-assumed), all SUGGESTION / informational, non-blocking by design.
• Should land after perf(mcp): cap mem_context output budget (#1039) #1074 merges to keep the reviewed candidate untouched.

[danielgap]

Filed from the advisory findings of the #1039 review. Fully scoped: one small PR in internal/mcp after #1074 merges. Feel free to assign me.