fix(db): persist tools by class key, not localized display name

[naw103]

Summary

After the recent i18n changes (commits c1dbabd / 14eca77 / c1b6460), MyTool.name became a locale-dependent display string. db_utils.save_tool still stores that value, and db_utils.load_tools uses it as a key into TOOL_CLASSES — whose keys are class identifiers like CustomFileWriteTool. Because e.g. t('tool.custom_file_write') resolves to "Write File" under en.json, every subsequent app start raises:

KeyError: 'Write File'

…in load_tools -> load_agents -> load_data. This reproduces for anyone on any locale as soon as a tool row exists in the DB.

What this PR does

• save_tool now stores the stable TOOL_CLASSES key (CustomFileWriteTool) instead of the translated tool.name ("Write File").
• load_tools accepts either format:
  • New rows: direct lookup on the class key.
  • Legacy rows: probes each registered class's current .name to map the stored display string back to a class.
• Legacy rows that successfully resolve are transparently rewritten with the stable key, so the migration is one-shot on the next load.
• Unknown tool rows log a warning and are skipped instead of crashing the entire load_data pass.

Repro (before this PR)

1. Fresh clone on main, run the app.
2. Create any tool (e.g. Custom File Write Tool) and restart the app.
3. load_agents -> load_tools raises KeyError: 'Write File'.

Test plan

• Fresh DB, create CustomFileWriteTool, restart -> tool loads.
• Existing DB with name='Write File' -> row loads and is rewritten to CustomFileWriteTool on first read.
• Switch locale to zh and restart -> tools still load (persisted key is locale-independent).
• TOOL_CLASSES entry removed -> that row is skipped with a warning; other tools still load.

Notes

• No schema changes; migration happens in-place on next load_tools call.
• Only app/db_utils.py is touched.