why moved code is not colored in git diff?

See the documentation for --color-moved/colormoved in git-diff(1):

--color-moved[=<mode>]

Moved lines of code are colored differently. It can be changed by the diff.colorMoved configuration setting. The <mode> defaults to no if the option is not given and to zebra if the option with no mode is given. The mode must be one of:

• no
  Moved lines are not highlighted.

• default
  Is a synonym for zebra. This may change to a more sensible mode in the future.

• plain
  Any line that is added in one location and was removed in another location will be colored with color.diff.newMoved. Similarly color.diff.oldMoved will be used for removed lines that are added somewhere else in the diff. This mode picks up any moved line, but it is not very useful in a review to determine if a block of code was moved without permutation.

• zebra
  Blocks of moved text of at least 20 alphanumeric characters are detected greedily. The detected blocks are painted using either the color.diff.{old,new}Moved color or color.diff.{old,new}MovedAlternative. The change between the two colors indicates that a new block was detected.

• dimmed_zebra
  Similar to zebra, but additional dimming of uninteresting parts of moved code is performed. The bordering lines of two adjacent blocks are considered interesting, the rest is uninteresting.

specifically, that the default is zebra and that it detects

Blocks of moved text of at least 20 alphanumeric characters

. my $ctx = shift; doesn’t contain at least 20 alphanumeric characters. If you use git diff --color-moved=plain, or add # ten more ANs to the end of the line, your example will be highlighted as moved.

Note there is another scenario where colored moved code (when the amount of code is enough) would have an improper side-effect:
"git diff --color-moved --cc --stat -p" did not work well due to funny interaction between a bug in color-moved and the rest.

This has been fixed in Git 2.21 (Feb. 2019)

See commit dac03b5, commit 04b19fc, commit 8290faa, commit 8817f0c, commit 48edf3a, commit 426fd36 (24 Jan 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 5d2710b, 05 Feb 2019)}

diff: clear emitted_symbols flag after use

There's an odd bug when "log --color-moved" is used with the combination of "--cc --stat -p": the stat for merge commits is erroneously shown with the diff of the next commit.

The included test demonstrates the issue.
Our history looks something like this:

A-B-M--D
   \ /
    C

When we run "git log --cc --stat -p --color-moved" starting at D, we get this sequence of events:

1. The diff for D is using -p, so diff_flush() calls into diff_flush_patch_all_file_pairs(). There we see that o->color_moved is in effect, so we point o->emitted_symbols to a static local struct, causing diff_flush_patch() to queue the symbols instead of actually writing them out.
   We then do our move detection, emit the symbols, and clear the struct. But we leave o->emitted_symbols pointing to our struct.

2. Next we compute the diff for M. This is a merge, so we use the combined diff code.
   In find_paths_generic(), we compute the pairwise diff between each commit and its parent. Normally this is done with DIFF_FORMAT_NO_OUTPUT, since we're just looking for intersecting paths. But since "--stat --cc" shows the first-parent stat, and since we're computing that diff anyway, we enable DIFF_FORMAT_DIFFSTAT for the first parent. This outputs the stat information immediately, saving us from running a separate first-parent diff later.
   But where does that output go? Normally it goes directly to stdout, but because o->emitted_symbols is set, we queue it. As a result, we don't actually print the diffstat for the merge commit (yet), which is wrong.

   3. Next we compute the diff for C. We're actually showing a patch again, so we end up in diff_flush_patch_all_file_pairs(), but this time we have the queued stat from step 2 waiting in our struct.
      We add new elements to it for C's diff, and then flush the whole thing. And we see the diffstat from M as part of C's diff, which is wrong.

So triggering the bug really does require the combination of all of those options.