filtered_graph: num_vertices is an index bound, not a count #690

num_vertices(g) is used for two different things in BGL:

1. as a vertex count (emptiness checks, loop bounds, sampling)
   

   graph/include/boost/graph/connected_components.hpp

   Lines 72 to 73 in ddce215

   	if (num_vertices(g) == 0)
   	return 0;

2. and as an upper bound on vertex indices to size property arrays.
   

   graph/include/boost/graph/connected_components.hpp

   Lines 106 to 108 in ddce215

   	auto index_map = get(vertex_index, g);
   	auto color_map = ::boost::make_two_bit_color_map(num_vertices(g), index_map);
   	depth_first_search(g, vis, color_map);

// base graph has vertices 0 1 2 3 4, the filter keeps 0 2 4
std::vector<color> color_map(num_vertices(fg));

// num_vertices(fg) is 5, so color_map[4] is valid
// if it returned 3, color_map[4] would be out of bounds
color_map[get(vertex_index, fg, 4)] = ...;

Bug: Since num_vertices(fg) doesn't match what vertices(fg) yields, every algorithm that uses it as a count can go wrong once vertices are filtered out:

• connected_components returns max() + 1 on an empty filtered graph: #231
• sequential_vertex_coloring read out of bounds: #627, fixed in #630
• random_vertex / random_edge can advance past the end of the filtered range
• vf2_sub_graph_iso never reports a mapping on a vertex-filtered graph. The docs say it was patched to use std::distance, but the fix in #282 was never merged.
• scale_graph and warren_transitive_closure dereference or step past the end when every vertex is filtered out
• stoer_wagner_min_cut takes its phase count from num_vertices

Users hit this too: Rosetta, Hyperscan and IfcOpenShell all carry comments and workarounds for it, and BGL has its own count_vertices in isomorphism.hpp.

Proposal

1. Add vertex_index_bound(g) / edge_index_bound(g) (names TBD), defaulting to num_vertices(g) / num_edges(g). Nothing changes for existing graphs.
2. Move algorithms to the bound when sizing property storage, and keep num_vertices for counting.
3. Then make filtered_graph's num_vertices / num_edges return the real count (O(V) or cached, O(1) when the predicate is keep_all).

Step 3 silently breaks user code that does std::vector<T> v(num_vertices(fg)) on a vertex-filtered graph and indexes it by vertex index. It compiles and then writes out of bounds. A search of public code found only a handful of such cases (bark, two OpenCV books, a BGL test), but it should still go with a release that already breaks things, plus a loud release note.

For #231 itself, fixing the call sites is enough.