Add no-string-coerce-error lint rule

[danielchen0]

Summary

• Adds a new no-string-coerce-error lint rule that flags String(error) in the else branch of error instanceof Error ternaries
• String() on a non-Error object produces '[object Object]' — the rule suggests JSON.stringify() instead to preserve object structure
• Includes 6 test cases covering variable names, nested calls, and false positive avoidance

Test plan

• All 240 existing tests pass
• 6 new tests for the rule cover flagging, nesting, and false positives

[arnavsurve]

Looks good. Clean implementation that follows the established patterns in the codebase.

What the rule does: Flags String(x) in the else branch of x instanceof Error ternaries, suggesting JSON.stringify(x) instead. This catches the common footgun where String() on a non-Error object (e.g. a plain object thrown as an error) produces the unhelpful '[object Object]'.

What I checked:

• The recursive containsStringCall correctly walks child nodes using VISITOR_KEYS, catching nested usages like new Error(String(err))
• Variable name matching between the instanceof check and the String() call prevents false positives
• The rule correctly scopes to only instanceof Error (not custom subclasses), which matches the intended use case of catch-all error handling
• Test coverage is solid: 6 tests covering the positive case, variable name variants, nested calls, and three false-positive avoidance cases
• All CI checks pass across Node 18/20/22
• README, rule index, and test count are all updated consistently

One minor pre-existing nit (not from this PR): the README intro still says "all 31 rules" on line 17, while the actual count is now 34. Could be fixed in a follow-up.

🤖 Generated with Claude Code

[arnavsurve]

Nit: The message says String(x) always produces '[object Object]', but that's only true for plain objects -- for strings/numbers it works fine. Since the else branch of instanceof Error could receive anything (string, number, object), the message is slightly overstated. Consider something like: "String(${errorName}) may produce '[object Object]' for non-Error objects. Consider JSON.stringify(${errorName}) to preserve structure." -- but this is very minor, fine to leave as-is.