docs(profile): point general contact at the documented support address

[kyle-sexton]

Closes #68

Summary

profile/README.md's Contact section gave info@melodicsoftware.com as the org contact address, which contradicted SUPPORT.md's routing. The profile page is the org's public landing page, so the address it gives is the one people actually use.

The issue's premise needs one correction before the fork can be picked. The issue body's table lists info@ as documented in "profile/README.md only" and its purpose as "undocumented." That is not the case: CODE_OF_CONDUCT.md line 39 uses it as the Contributor Covenant enforcement contact, i.e. the address for reporting abusive or harassing behavior. So info@ is a real address with a documented purpose, and the count was never three undocumented candidates.

(The triage comment's own sentence, "Neither policy file mentions info@ anywhere," was scoped to SECURITY.md and SUPPORT.md and is true as written. It went on to conclude "the report's claim holds," which is the part that carried the issue body's error forward, because the search covered those two files rather than all five policy files.)

Fix

profile/README.md's Contact section now reads <support@melodicsoftware.com>. One line, one file.

That resolution matches neither of the issue's two forks verbatim, so here is the reasoning explicitly:

• Fork 1 ("info@ is distinct and monitored, so document its purpose and keep the profile pointing at it") is half-satisfied already: its purpose is documented, in CODE_OF_CONDUCT.md. But that documented purpose is conduct reports, which is not what a profile page's Contact section means. Keeping the pointer would route general enquiries into the conduct-report inbox.
• Fork 2 ("info@ is not a distinct monitored inbox, so point the profile at support@") reaches the right destination by the wrong reasoning, since info@ is real.

The correct resolution takes fork 2's edit on fork 1's facts: SUPPORT.md already assigns support@melodicsoftware.com to "anything else," which is precisely the scope of a general Contact section, so general contact now has one documented answer. info@ keeps its single documented job.

Nothing is added and no inbox is retired: the three addresses each now have exactly one documented purpose (security@ for vulnerabilities per SECURITY.md, support@ for everything else per SUPPORT.md, info@ for conduct reports per CODE_OF_CONDUCT.md), which satisfies the acceptance criterion that no contradiction remains between profile/README.md and the policy files.

CODE_OF_CONDUCT.md is deliberately untouched. It is verbatim Contributor Covenant v2.1 and .claude/ai-slop.json excludes it from automated edits for that reason; its use of info@ is correct as it stands.

On the "excluded from automated edits" note in the issue's provenance. That refers to the /code-tidying:batch-simplify sweep's own exclusion list, not a repository-level prohibition. Checked before editing: CLAUDE.md, README.md, .editorconfig, .editorconfig-checker.json, .gitattributes, lychee.toml, and .claude/settings.json carry no rule restricting edits to profile/README.md. The only repo-level mention is README.md line 26, which describes what the file renders as. .claude/ai-slop.json lists it under em_dash_allowed_paths, which relaxes a rule rather than blocking edits.

Verification

• npx markdownlint-cli2@0.23.2 --config .markdownlint-cli2.jsonc profile/README.md -> 0 issues.
• grep -rn "info@\|support@\|security@" across all seven tracked policy/profile Markdown files, before and after, to confirm the full address inventory and that the only remaining info@ is the Code of Conduct's.
• Diff is a single line; the autolink form <address> is preserved, so GFM still renders it as a mailto link.
• Full ci-status aggregate on this PR.

Related

• Refs CODE_OF_CONDUCT.md line 39, the pre-existing documented use of info@ that the issue's premise missed.
• No change to SECURITY.md or SUPPORT.md; their documented purposes are out of scope per the issue.