fix: harden TypeScript project and async detection

[GDownes]

Problems

1. Running desloppify scan --path libs/cognito-deploy-contracts in a TypeScript monorepo creates tsconfig.desloppify.json at the repository root with a hard-coded extends: ./tsconfig.app.json. Library projects commonly own tsconfig.json instead, so the unused detector type-checks the wrong project or falls back after a timeout.
2. The async_no_await smell detector treats the first { in a multiline typed parameter as the function body. It therefore flags async declarations that contain direct await expressions whenever their argument uses an inline object type.

Fixes

• Locate the nearest owning tsconfig.app.json or tsconfig.json, create the temporary override beside it, and extend that config. If no TypeScript config exists, use the existing source-based fallback directly.
• Parse the complete parameter list before locating an async declaration body, including multiline inline-object parameters and return types, then inspect the real body for await.
• Add regression coverage for both defects.

Validation

• pytest desloppify/languages/typescript/tests/test_ts_unused.py -q — 19 passed
• pytest desloppify/languages/typescript/tests/ -q — 429 passed
• Focused async smell helper suite — 89 passed
• python -m pytest desloppify/tests/ -q — 5651 passed, 153 skipped, 3 unrelated Bash failures
• The same 3 Bash failures reproduce without these changes
• Verified against WorkOrderGuard: library-local TypeScript config resolution works, and false async_no_await findings fell from 10 to 0

[awdemos]

Reviewed alongside #721 (same two bugs, different designs; the two PRs textually conflict in unused.py). Where each wins, verified empirically against main:

• Your tsconfig selection is the correct design: it preserves main's tsconfig.app.json preference — on a Vite-style root with a {"files": []} solution tsconfig.json plus a real tsconfig.app.json, yours extends ./tsconfig.app.json (same as main) where fix: harden TypeScript scanning and plan resolution #721's _find_base_tsconfig picks the solution stub and silently type-checks nothing. Your source-based fallback for tsconfig-less projects also fixes a main gap that fix: harden TypeScript scanning and plan resolution #721 keeps.
• fix: harden TypeScript scanning and plan resolution #721's async fix is broader: it rewrites _extract_function_body in detector_core.py (all 4 call sites, arrow functions included), while this PR only patches named async function declarations — arrow functions with object-typed params still go through the old buggy extraction here.
• fix: harden TypeScript scanning and plan resolution #721 additionally carries two real workflow fixes (step_completion fail-closed is a genuine bug reproduced on main) plus an unsubstantiated snapshot claim (test passes pre/post) and some scope creep.

The clean consolidation: land this PR's unused.py variant + #721's _extract_function_body and step_completion changes, with the snapshot hunk either made to fail on main or dropped. Both PRs are individually well-tested — this is about avoiding two conflicting designs for the same file merging in some third, worse combination.