fix: allow --recursive to delete document paths and their subcollections

[hummer98]

Root cause

firex delete <doc-path> --recursive was unconditionally rejected by an
artificial CLI-side check in src/commands/delete.ts:

if (recursive && !isCollection) {
  this.handleError('--recursive can only be used with collection paths', 'validation');
  return;
}

The firebase-admin SDK's Firestore.recursiveDelete() accepts either a
CollectionReference or a DocumentReference and recursively deletes
everything underneath, subcollections included — there was no underlying
technical reason to disallow document paths. The restriction forced
callers to manually enumerate every subcollection and delete each one
individually before deleting the document itself.

Fix

• Removed the CLI-side restriction in src/commands/delete.ts.
• Added BatchProcessor.deleteDocument() in src/domain/batch-processor.ts,
  which deletes a document's subcollections (reusing the existing
  deleteCollection() recursion, the same pattern already used for the
  collection-path case) and then deletes the document itself.
• DeleteCommand now routes document path + --recursive to a new
  deleteDocumentRecursive handler that calls
  BatchProcessor.deleteDocument, the document-path analogue of how
  collection path + --recursive already routes to
  BatchProcessor.deleteCollection.
• Added a confirmation prompt string (prompt.confirmDeleteDocumentRecursive,
  both locales) so the confirmation message makes clear subcollections are
  included.

Checked src/mcp/tools/delete.ts (the MCP tool wrapper): it does not
duplicate this validation — it has no equivalent guard to remove, so no
change was needed there for this issue.

Tests

• src/domain/batch-processor.test.ts: new deleteDocument describe
  block covering delete-with-no-subcollections, recursive
  subcollection deletion, and confirmation-denied cases.
• src/commands/delete.test.ts: new tests confirming a document path is
  still classified correctly, that --recursive on a document path now
  routes to BatchProcessor.deleteDocument (the old restriction is gone),
  and a regression test confirming collection path + --recursive still
  routes to BatchProcessor.deleteCollection as before.

npm run typecheck, npm test (1046 tests), and npm run build all pass
locally. npm run lint could not be run — this repository has no ESLint
config file checked in at any point in its history (confirmed on
master), so npm run lint fails with "ESLint couldn't find a
configuration file" independent of this change; this is a pre-existing
issue unrelated to this fix.

Fixes #5