app-server: align dynamic tool identifiers with Responses API

[eternal-openai]

Why

Codex currently accepts dynamic tool names and namespaces that the upstream Responses function-tool path does not actually support. In practice, that means app-server can register a dynamic tool successfully and only discover later that the LLM-facing tool contract will reject or mishandle it.

This PR tightens the app-server-side dynamic tool contract to match the Responses API before we stack dynamic tool hook support on top of it.

What changed

• validate dynamic tool name against the Responses function-tool identifier contract: ^[a-zA-Z0-9_-]+$, length 1..128
• validate dynamic tool namespace the same way, with the Responses namespace length limit 1..64
• reject namespaces that collide with the always-reserved Responses runtime namespaces such as functions, multi_tool_use, file_search, web, browser, image_gen, computer, container, terminal, python, python_user_visible, api_tool, tool_search, and submodel_delegator
• escape invalid identifiers in error messages so control characters do not spill raw into logs or client-visible error text
• document the tightened dynamic tool identifier contract in codex-rs/app-server/README.md
• add both unit coverage for the validator and an app-server integration test that rejects a thread/start request with Responses-incompatible dynamic tool identifiers

Verification

• cargo test -p codex-app-server validate_dynamic_tools_
• cargo test -p codex-app-server --test all thread_start_rejects_dynamic_tools_not_supported_by_responses