bug(tools): find_dead_code is hard-capped at 50 results, making exclude_decorated_with appear to do nothing #1606

Split out of #1595 (report 9 of 9) — filed by @rrodriguesNutrium, credit to them.

code_finder.py:895-896:

ORDER BY func.path, func.line_number
LIMIT 50

The cap is applied after the decorator filter, so excluded rows are silently backfilled by the next ones in path order. The returned count is 50 either way.

Measured on a 2,861-file Android codebase (3,683 files indexed, 15,859 Function nodes):

find_dead_code()                            -> 50     (capped)
find_dead_code(exclude_decorated_with=[..]) -> 50     (capped; appears to filter nothing)

same predicate, LIMIT lifted:
find_dead_code()                            -> 7,141
find_dead_code(exclude_decorated_with=[..]) -> 1,055   (-85%)

A filter that genuinely removes 6,086 false positives — @Test, Hilt @Provides/@Binds, Room @TypeConverter — presents as doing nothing. And the 50 you do see are whichever functions sort first by path, so they cluster in one or two files rather than sampling the codebase.

Three independent improvements:

1. Return the total alongside the page — {"potentially_unused_functions": [...], "total": 7141}. The count is the most useful number and is currently unobtainable.
2. Make the limit a parameter with 50 as the default, rather than hard-coded. Note Fixes #1542: Parameterize relationship query limits, add truncation flags & CLI support #1594 has since landed TOOL_RESULT_LIMITS plumbing with truncated/result_limit flags for the relationship queries — find_dead_code should use the same mechanism (find_dead_code already has a built-in default of 50 in utils/tool_limits.py).
3. Order so it samples rather than clusters, or at minimum document that the result is a path-ordered prefix.

This was invisible until the is_dependency bug (#1595, report 7) was fixed, because the tool returned [] unconditionally.