docs(reference): correct artifact_get/log_get reply event and tasking syntax

[lc-cbot]

Summary

artifact_get and log_get are the same sensor command, but the endpoint command
reference documented them as two separate commands, with different reply events and
different parameters. Only the log_get entry had the reply event right.

Everything below was corrected against a live organization rather than from the
existing docs.

What was wrong

Item	Documented	Actual
artifact_get reply event	FILE_GET_REP (section), N/A (table)	LOG_GET_REP
log_get reply event in table	N/A	LOG_GET_REP
log_get parameters	source, predicate	--file / --source (exactly one required), --type, --payload-id, --days-retention, --is-ignore-cert
log_get --predicate	documented for macOS	rejected: unknown argument --predicate
log_get platforms	Windows / macOS only	macOS, Windows and Linux
LOG_GET_REP contents	undocumented	receipt with ERROR and PAYLOAD_ID — not the collected file
CLI tasking syntax	limacharlie sensor task <SID> <cmd>	not a valid command

Changes

• artifact_get now points at log_get as an alias. log_get holds the full entry,
  since it is the name that matches the emitted LOG_GET_REP event.
• Documented the two retrieval models, which was the underlying source of confusion:
  file_get returns file bytes inline in FILE_GET_REP, whereas log_get
  uploads out-of-band to Artifact Collection and returns only a PAYLOAD_ID
  receipt. Retrieving the artifact via limacharlie artifact download is a separate
  step that was not documented anywhere.
• Filled in the LOG_GET_REP event reference entry with its fields, platforms and
  cross-links.
• Replaced all 58 limacharlie sensor task examples with
  limacharlie task send --sid <SID> --task '...', and added a note pointing at
  task request for callers that want to block for the reply and
  task reliable-send for offline sensors. Windows paths in those examples were
  double-escaped for a double-quoted shell string; single-quoting also stops $a in
  the yara_scan examples from being expanded away by the shell.

This PR deliberately does not modify the file_get or FILE_GET_REP entries beyond
the tasking-syntax change — see follow-up 1.

Follow-ups not included here

1. Roughly twenty commands on this page document parameters that the tasking API
   rejects. The pattern is consistent: a plausible-looking flag where the command
   actually takes a positional argument, or a differently-named flag. Confirmed cases
   include file_get --file_path, file_del --file_path, file_hash --file_path,
   file_info --file_path, file_mov --src_path/--dst_path, dns_resolve --hostname,
   exfil_add, exfil_del --id, fim_add/fim_del --file_path, mem_read,
   mem_find_handle --needle, mem_find_string --strings, epp_scan --file_path,
   run --command, and yara_scan --rule. Worth a dedicated pass, since each needs
   verifying individually.
2. The value format for log_get --source is not verified. The flag is confirmed
   to exist and to be mutually exclusive with --file, so it is documented that far
   and no further — the previous --source "Security" example was left out rather
   than carried over unverified.