Exercise 1: match vs. term, and the Classic Beginner Mistake — Possible Solution
====================================================================

WHAT A match QUERY DOES
------------------------------
Per this chapter, "a match query analyzes the search input the same
way the field was analyzed at index time... meant for genuine
full-text search against analyzed text fields. Searching 'quick fox'
can match a document containing 'The Quick Brown Fox,' because both
go through identical lowercasing and tokenization." A match query
takes the search text and runs it through the SAME analysis pipeline
(per search1-4's own tokenization/normalization material) the
original field's own content went through when it was indexed, then
compares the resulting analyzed terms.

WHAT A term QUERY DOES
------------------------------
Per this chapter, "a term query does not analyze the input at all —
it looks for an exact match against the raw indexed term, meant for
exact-value fields (an ID, a status enum, a keyword-mapped field)." A
term query takes the search value exactly as given and looks for an
EXACT match against whatever is actually stored in the inverted index
— no lowercasing, no tokenization, no normalization applied to the
search input at all.

THE CLASSIC BEGINNER MISTAKE, WITH A CONCRETE BEFORE/AFTER EXAMPLE
------------------------------
Per this chapter's own warn-box, "a term query for 'Quick Fox' against
a text field will typically return zero results, since the inverted
index actually stores lowercased, tokenized terms like quick and fox,
not the raw string 'Quick Fox.'"

BEFORE (broken): a query like { "term": { "description": "Quick Fox"
} } is run against a text field. Because term never analyzes the input,
it looks for a document whose inverted index literally contains the
exact term "Quick Fox" (capitalized, unsplit, with the space intact)
— but per search1-4's own analyzer material, the actual indexed terms
for a document containing "The Quick Brown Fox" would be the separate,
lowercased tokens "the," "quick," "brown," "fox" — never "Quick Fox"
as one single term at all. The query returns zero results, even
though the document genuinely, intuitively "contains" the phrase.

AFTER (working): per this chapter, "the exact same search, run as a
match query instead, works correctly — because match analyzes the
input identically to how the field was analyzed at index time." Using
{ "match": { "description": "Quick Fox" } } instead runs the search
input "Quick Fox" through the same analysis pipeline, producing the
lowercased terms "quick" and "fox" — which DO match the terms actually
present in the document's own inverted-index entries, correctly
returning the document.

WHY THIS WORKS AS AN ANSWER
------------------------------
It defines both query types precisely using the chapter's own wording,
and constructs the exact concrete before/after example the chapter's
own warn-box describes, explaining specifically why the term query
fails and the match query succeeds for the identical search intent.