claw-wall: raise channel-awareness max_chars default and expose a public knob

[mostlydev]

Problem

The channel-awareness feed (uncursored 24h raw window) is capped at 8 KB by default. In channels with even modest activity that's only a handful of messages, which defeats the point of the 24h surface — agents see a tiny tail rather than the day. The same default (conversationWallFeedMaxChars = 8 * 1024 in cmd/claw/compose_up.go:52) is used by both feeds, and the v0.15.0 channelogue flagged this explicitly: "Phase 1 ships without a public config surface so the defaults can keep moving."

Two problems compound:

1. The default is too low. A Discord line in the feed format (timestamp + author + content) averages ~1 KB. 8 KB ≈ 5–10 messages. 24h of modestly-active conversation (~5 msg/hr) is ~120 KB; a few hours of very-active conversation (~60 msg/hr) is ~180 KB.
2. channel-awareness has no public override knob. conversationWallChannelAwarenessContext() in compose_up.go:1901 returns hardcoded settings and ignores pod config entirely. channel-context (cursored delta) already honors x-claw.context.channel.{since,limit,max-chars,buffer} at pod and service level via applyConversationWallChannelContext; the awareness feed does not.

Proposed fix

1. Bump the default 4×: conversationWallFeedMaxChars and the matching server-side defaultTailMaxChars in cmd/claw-wall/store.go:20 go from 8 * 1024 to 32 * 1024. That comfortably covers a few hours of very-active conversation in either feed without changing pod YAML.

2. Wire channel-awareness to honor the existing x-claw.context.channel config. Single knob raises both feeds together. Operators who want larger awareness windows (a full day of active channels) bump max-chars once at pod or service level, just like they already do for channel-context.

Tradeoff considered: a separate x-claw.context.channel-awareness block would let awareness diverge from channel-context. Rejected for v1 because the two feeds serve overlapping purposes — both surface recent channel history into prompts — and a single knob is simpler. If a real use case for divergence appears, add the second block then.

Scope

In:

• Bump both constants.
• Extend conversationWallChannelAwarenessContext() to take (*pod.Pod, *pod.Service) and apply pod-level then service-level overrides via the existing applyConversationWallChannelContext.
• Test coverage for the new override path and the default bump.
• Changelog entry under Unreleased (no release pin bumps in this PR — that's the maintainer's call at release time).

Out:

• Separate x-claw.context.channel-awareness block.
• Token-budget guard rails (Anthropic 200K context budgeting is upstream-of-cllama work).
• Per-tool-call max_chars for the retrieval tools (search_channel_context, get_channel_messages) — those already accept max_chars as a tool argument, behavior unchanged.

Acceptance

• Default cap on a fresh pod with no x-claw.context.channel config is 32 KB on both feeds.
• Setting x-claw.context.channel.max-chars: 131072 at pod or service level raises both feeds to 128 KB.
• claw-wall honors the URL max_chars value and emits cap_reason=max_chars when truncation fires.
• Tests: pod parser default → 32 KB, override → custom value, awareness feed URL includes the resolved max_chars.