[Bug] Slack Channel fails with "not_authed" / Credential injection failure & CLI config amnesia (v0.12.0)

[Ridoc]

Environment:

• OS: Linux Mint
• IronClaw Version: v0.12.0
• Database: libSQL (embedded)
• Storage Method: Environment variable (SECRETS_MASTER_KEY in ~/.ironclaw/.env)

Description:
The Slack WASM channel fails to send outbound messages, consistently returning a Slack API error: not_authed. Despite successfully receiving the webhook (POST 200) and the LLM generating a response, the outbound HTTP request to the Slack API fails because the credentials are not being injected into the request. Furthermore, the CLI config command exhibits "amnesia" when trying to store/retrieve these specific tokens.

Steps to Reproduce & Observed Behavior:

Scenario A: Configuring via Web UI

1. Enter xoxb-... token and Signing Secret via the Web UI.
2. The logs show the credentials are read successfully:
   INFO Credentials available for on_respond credential_count=2 credential_names=["SLACK_SIGNING_SECRET", "SLACK_BOT_TOKEN"]
3. A message is triggered via Slack. IronClaw processes it and attempts to respond.
4. The logs show the injection fails entirely:
   INFO URL after credential injection url_changed=false
5. The request fails:
   ERROR WASM on_respond returned error error=Slack API error: not_authed
   Suspected reason: The Web UI stores the keys in UPPERCASE (SLACK_BOT_TOKEN), but the WASM plugin seems to strictly expect lowercase (slack_bot_token) during the on_respond injection phase, resulting in url_changed=false.

Scenario B: Configuring via CLI (The "Amnesia" Bug)
To bypass the uppercase issue from the Web UI, I attempted to set the keys explicitly in lowercase via the CLI:

1. Run: ironclaw config set slack_bot_token "xoxb-..."
2. Output: Set slack_bot_token = xoxb-... (Appears successful)
3. Immediately run: ironclaw config get slack_bot_token
4. Output: Error: Setting not found: slack_bot_token
   Note: The SECRETS_MASTER_KEY was correctly exported and sourced during this test. The CLI successfully reports saving the key, but it cannot retrieve it a second later.

Scenario C: Configuring via .env file

1. Added slack_bot_token="..." and slack_signing_secret="..." directly to ~/.ironclaw/.env.
2. Restarted IronClaw.
3. Triggered a Slack message.
4. Logs show the .env variables are completely ignored by the channel:
   INFO Credentials available for on_http_request credential_count=0 credential_names=[]

Expected Behavior:

1. The CLI config set/get commands should reliably store and retrieve credentials without "forgetting" them.
2. The Slack WASM channel should correctly normalize (or be case-insensitive to) credential names like SLACK_BOT_TOKEN vs slack_bot_token.
3. The url_changed flag should flip to true during on_respond, injecting the token correctly to prevent the not_authed error from Slack.

Relevant Logs (from Scenario A):

INFO Calling WASM on_respond content_preview=Hallo! How can I assist you today?
INFO WASM http_request called method=POST original_url=https://slack.com/api/chat.postMessage body_len=101
INFO URL after credential injection url_changed=false
INFO HTTP response received status=200 body_len=114
INFO http_request completed successfully status=200
ERROR WASM on_respond returned error error=Slack API error: not_authed
ERROR Failed to send response to channel channel=slack error=Failed to send response on channel slack: Channel slack callback failed: Slack API error: not_authed

[Ridoc]

just proved that the CLI failure in v0.12.0 isn't just isolated to injecting WASM secrets, it's completely failing to persist any standard configuration variables to the libSQL database (or at least, failing to read them back out).

The config set command is effectively broken across the board.

Since the CLI is completely untrustworthy right now, I successfully bypassed the database entirely and hardcode this into the bootstrap environment variables.