The dblink docs recommend using dblink_fdw as the FDW for this purpose, which would only accept legal connstr options. However, I can see the point of using a postgres_fdw server instead, and considering that dblink isn't actually enforcing use of any particular FDW type, it seems like the onus should be on it to be more wary of what the options are.
I have to admit, this was the first I'd heard of dblink_fdw. I'm glad it exists, though. And yes, I'd like to be able to use postgres_fdw entries because there's value in knowing that the connection for your ad-hoc SQL exactly matches the connection used for other FDW tables.
It looks like this might be fairly easy to fix by having get_connect_string() use is_valid_dblink_option() to check each option name, and silently ignore options that are inappropriate.
From what I can tell, it is very straightforward, the context oids are set up just a few lines above where the new is_valid_dblink_option() calls would be.
I'm happy to write the patch, for both v10 and any back-patches we feel are necessary. However, I suspect with a patch this trivial that reviewing another person's patch might be more work for a committer than just doing it themselves. If that's not the case, let me know and I'll get started.