tl;dr
No, you didn't make a typo when setting up the apache2 server. The process name is not read from a configuration file, it is read from the /proc/[pid]/comm kernel interface, and the truncation occurs there.
It appears to be a particular apache2 module, mod_perl, that is responsible for replacing the basename apache2 with the (truncated) path /usr/sbin/apach.
Details
The systemctl status command reads the process name from the kernel's process information pseudo-filesystem at /proc/[pid]/comm where the process ID [pid] is the apache2 Main PID. You can verify this by running systemctl status apache2 under strace, for example:
$ systemctl show -P MainPID apache2.service
6525
$ strace -P /proc/6525/comm -e trace=%file,read,write systemctl --no-pager status apache2 >/dev/null
openat(AT_FDCWD, "/proc/6525/comm", O_RDONLY|O_CLOEXEC) = 4
newfstatat(4, "", {st_mode=S_IFREG|0644, st_size=0, ...}, AT_EMPTY_PATH) = 0
read(4, "/usr/sbin/apach\n", 1024) = 16
read(4, "", 1024) = 0
+++ exited with 0 +++
You can see that it's reading the string /usr/sbin/apach\n, a total of 16 characters including the terminating newline \n. That length limit is imposed by the kernel TASK_COMM_LEN parameter, as noted in man proc:
/proc/[pid]/comm (since Linux 2.6.33)
This file exposes the process's comm value—that is, the command
name associated with the process. Different threads in the same
process may have different comm values, accessible via
/proc/[pid]/task/[tid]/comm. A thread may modify its comm
value, or that of any of other thread in the same thread group
(see the discussion of CLONE_THREAD in clone(2)), by writing to
the file /proc/self/task/[tid]/comm. Strings longer than
TASK_COMM_LEN (16) characters (including the terminating null
byte) are silently truncated.
This file provides a superset of the prctl(2) PR_SET_NAME and
PR_GET_NAME operations, and is employed by pthread_setname_np(3)
when used to rename threads other than the caller. The value in
this file is used for the %e specifier in /proc/sys/ker‐
nel/core_pattern; see core(5).
If you look at almost any other process, you will see that its /proc/[pid]/comm file contains just the program's basename. The 16-character TASK_COMM_LEN value suggests it is not intended to contain path components - and indeed if you install a basic apache2 server, that's exactly what you see. So what is changing it to /usr/sbin/apach?
Summoning up some google-fu, it turns out the answer is mod_perl. Specifically, in this comment on Red Hat Bugzilla – Bug 782369
A process can call prctl(PR_SET_NAME) to set it's task name (task->comm) in the kernel, as long as the name is under 16 characters. If you have mod_perl included in httpd, it calls prctl and sets the name to '/usr/sbin/httpd'.
Why it does this, I have absolutely no clue. But it does.
("httpd" is what RedHat calls apache2). If you're running apache2 in a testing environment, you can verify that's the culprit by temporarily disabling the mod_perl module:
sudo a2dismod perl
sudo systemctl restart apache2
and you should see the process name in the systemctl status output revert back to (apache2). You can re-enable the mod afterwards with
sudo a2enmod perl
and restarting the service again.
